Raid6 vs. Raid10

Linux-kezdő

Sziasztok.

Adott egy kis fájlszerver két hdd-vel szoftveres raid1-ben összefűzve. Van két elfekvő hdd, amit szeretnék a meglévők mellé beszerelni és az egészet összefűzni raid6-ban vagy raid10-ben.

Elég sok leírást, tesztet, véleményt olvastam pro és kontra, de nem tudom egyik mellett sem letenni a voksom. A raid10 felé hajlok, viszont nem tudom azon belül is melyik megoldást célszerű alkalmazni.
Az alábbi kérdések merültek fel:

- Hogy érdemes megvalósítani a raid10-et? Megcsinálni kézzel a két tükröt és ezekből a tömbökből egy raid0-t?
- Esetleg rábízni az mdadm-re és egyszerűen raid10-ként létrehozni a tömböket?
- Utóbbi esetén melyik layout-ot célszerű használni? Ha jól vettem ki, az f2 redundancia szempontjából a raid0+1-nek felel meg.
- Ha jól látom raid6 esetén a bővítés viszonylag egyszerűen megoldható, viszont a raid10 tömböt egy (kettő) hdd bővítéskor nulláról újra kell építeni?

A fontossági sorrend: redundancia, teljesítmény, méret.

Minden véleményt, hozzászólást, tanácsot szívesen fogadok.

EIK: Zoli

  • 3090 megtekintés

( mauzi v | 2009. 06. 08., h – 15:14 )

ne felejtsd el, hogy a RAID 5/6 pocsék írásra.

( zwei | 2009. 06. 08., h – 15:22 )

Raid10-re jobb az 1+0, vagyis ahogy te is irtad, hogy páronként tükrözöl, utána stripe-olsz.

1+0: 2-2 diszket először egymásra tükrözöl, majd a kapott két tükröt stripe-olod.
0+1: összestripe-olsz 2-2 diszket, majd a stripeolt volumokat összetükrözöd.

Az első esetben ha megdöglik egy diszked, akkor csak az egyik tükörpárt kell szinkronizálni, a második tükörpárod ép marad.

A második esetben ha megdöglik egy diszked, akkor teljesen szétesik a tükröd, és újra kell az egészet szinkronizálni.

Miértis???

"RAID 0+1 and RAID 1+0 may look very similar, but there is a distinct difference when it comes to redundancy. In a 4-disk configuration, both can survive losing 1 disk without any data loss. And both configurations will fail if you lose 3 disks. However, the probabilities of losing the RAID array are different if you lose 2 disks. The Linux MD raid10 has the same properties ad RAID 1+0."

Innen
--
Debian Linux rulez... :D

ezért:
"However, the probabilities of losing the RAID array are different if you lose 2 disks."

Raid0+1 esetén a 2. diszk kiesése 66%-os (2/3) eséllyel okoz adatvesztést , amíg raid 1+0 esetén ez 33% (1/3)

szerk:
továbbá raid 0+1 esetén álltalában a kiesett tükörfelet újra kell szinkronizálni (ez 4 diszkes felállás esetén full szinkron - vagyis mindkét diszk letükrözése a másik 2-re.)
raid 1+0 esetén csak a kiesett tükörpárt kell újraszinkronizálni (4 diszk esetén ez 1 db diszk tükrözése)

Nem piszka, csak hogy mindenki megértse... :D

Amivel én nem értettem egyet, az az hogy 4 diszkes konfignál 1 lemez kiesését melyik tolerálja jobban...
Szerintem mindegy, mert 1 kiesését minden gond nélkül túl kell hogy élje... Hogy a gép mennyit nyüsszög a javítás során?... :D

1+0: 2-2 diszket először egymásra tükrözöl, majd a kapott két tükröt stripe-olod.
0+1: összestripe-olsz 2-2 diszket, majd a stripeolt volumokat összetükrözöd.

Az első esetben ha megdöglik egy diszked, akkor csak az egyik tükörpárt kell szinkronizálni, a második tükörpárod ép marad.

A második esetben ha megdöglik egy diszked, akkor teljesen szétesik a tükröd, és újra kell az egészet szinkronizálni.

Itt 4 lemezről, és 1 meghibásodásról írsz!!!

A mostani válaszodban pedig 2 lemez kiesését elemezgeted...

"However, the probabilities of losing the RAID array are different if you lose 2 disks."

Raid0+1 esetén a 2. diszk kiesése 66%-os (2/3) eséllyel okoz adatvesztést , amíg raid 1+0 esetén ez 33% (1/3)

Ez totál igaz !!! :D

Melleseg:

továbbá raid 0+1 esetén álltalában a kiesett tükörfelet újra kell szinkronizálni (ez 4 diszkes felállás esetén full szinkron - vagyis mindkét diszk letükrözése a másik 2-re.)

Bármilyen tükörnél (RAID 1) a kiesett tükröt mindig újra kell szinkronizálni. (Függetlenül attól, hogy az esetleg hány diszket jelent.)
Bármilyen stripe/szelet (RAID 0) esetén a kiesett szeletrész a teljes RAID-et összedönti.

A hibaszámítások is ez alapján működnek (az idézett oldalon is).

Tehát 0+1 és 1+0 esetében azt kell megnézni, hogy adott "al-RAID" kiesett-e, vagy sem.
Ha igen, akkor a "fő-RAID"-ot is meg kell vizsgálni.

4 lemez 1 hibánál mindegy melyik hal el, mert:

RAID 1+0 -> "al-RAID 1"-ben előforduló hiba esetén egy csere és újraszinkronizálás megoldja a problémát. (2 diszk (1->1) szinkronizálódik össze.)

RAID 0+1 -> "al-RAID 0" hibája a "fő-RAID 1" -et is "degraded" állapotba viszi. Itt első lépés a RAID 0 visszahozása, és ilyenkor nincs szinkronizálás, hanem egy új tömb létrehozása. Ez után jön a RAID 1 szinkronizálás. (Virtuálisan itt 3 diszk "dolgozik", valójában pedig 2->2 diszk szinkronizálódik.)

2 elhalásnál pedig tényleg a RAID 1+0 az életrevalóbb, és persze a könnyebben helyreállíthatóbb is!

3+ elhalás pedig már mindegy :D

--
Debian Linux rulez... :D

"Amivel én nem értettem egyet, az az hogy 4 diszkes konfignál 1 lemez kiesését melyik tolerálja jobban"

Akkor hibásan nem értettél egyet, mert az eredeti kérdés az volt, melyiket érdemesebb használni.
SPOF szempontjából egyenértékű. (egyikben sincs.)

"Hogy a gép mennyit nyüsszög a javítás során?... :D"

Ha szerinted nem lényeg, akkor nem üzemeltettél olyan rendszert, amin esetleg 8-10 Tb diszk lógott, meg 20-30 adatbázis, és pár 10k felhasználó. Itt baromira nem mindegy, hogy 12 vagy 4 órát fut egy resilvering.
Az tényleg nem érdekes, hogy a gép mennyi nyüszög, de ha pl. nem fut le egy zárás vagy nyitás időben a megnőtt IO terhelés miatt, ott már azok is nyüszögnek, akik a fizetésedet adják. :)

"4 lemez 1 hibánál mindegy melyik hal el, mert:"

és ez után pontosan leírtad, hogy miért nem mindegy. :)

"(1->1) szinkronizálódik össze" vs. "2->2 diszk szinkronizálódik"

Ez utóbbi jóval lassabb is lehet mint az előbbi. (Minnél nagyobb a normál üzemi terhelés, annál lassabb.)

Összegzésül, 4 diszkes konfigban:

1 diszkhiba esetén, hibatűrés szempontjából: mindegy melyik
1 diszkhiba esetén helyreállítási idő (és IO terhelés szempontjából): raid10
2 diszkhiba esetén: raid10

Őszintén, gőzöm sincs mit szeretnél mondani, mert gyakorlatilag ugyanazt írtad le amit én is. Lehet, hogy rosszul fogalmaztam és számodra félreérthető voltam, de akkor is kb 4 sorban azt írtam le, amit te fél oldalon keresztül fejtegetsz.

Asszem, kár lenne válaszolnom az előbbiekre, de mégis megteszem... :D

Mivel ÉN "nem figyeltem" oda az eredeti bejegyzésre, ezért "hibásan" gondoltam, hogy a topic indító 4 lemezes rendszerről beszél... Pedig valójában azt kérdezte, hogy melyiket érdemesebb használni...

Adott egy kis fájlszerver két hdd-vel szoftveres raid1-ben összefűzve. Van két elfekvő hdd, amit szeretnék a meglévők mellé beszerelni és az egészet összefűzni raid6-ban vagy raid10-ben.

...

A fontossági sorrend: redundancia, teljesítmény, méret.

Ha a fontossági sorrendben a redundancia megelőzi a teljesítményt, akkor IMHO totál mindegy, hogy 01 vagy 10...
Igaz, hogy amíg 10-ánál a 3 tömbből 1, addig 01-nél 2 lesz degraded állapotú hiba esetén. Viszont ettől függetlenül még nincs adatvesztés !!!

IMHO 8-10 TB nem is sok...
IMHO 20-30 adatbázis sem...
IMHO pár 10k felhasználóval is lehet élni..
IMHO nem mindegy, mennyi idő alatt állnak vissza a tömbök, ha esetleg egy RAID hibát csak 99%-nál talál meg...
IMHO mindegy, mennyi idő alatt állnak vissza a tömbök, ha a többi szolgáltatás ezt nem érzi meg...
IMHO ilyen nagyobb rendszereknél HW RAID vezérlőket alkalmaznak, amelyek szinte teljesen elrejtik az OS elől, hogy éppen tömb újraépítés folyik...
IMHO elgondolkodnék egy ilyen nagy terheltségű rendszernél HA clusterek, elosztott rendszerek kiépítésén... Még akár "olcsó" megoldásban is.... Pl.így
AFAIK még szoftveres RAID esetében is lehet szabályozni az újraépítés sebességét Ha jól emlékszem

IMHO még mindig azt mondom, hogy 4 lemezes rendszer 1 hibás lemezénél mindegy, hogy 01 vagy 10, mert valószínű, hogy az új lemez beszerelése tovább tart, mint a parancsok kiadása, ami mellesleg számszerileg 01 esetében 1-el több, mint 10-nál...
AFAIK nem is kell megvárni a parancsok végrehajtódását...

Az első hozzászólásodban kijelentetted, hogy az 10 a jobb. Azonban nem magyaráztad meg, hogy miért?
A másodikban a 4 lemez 1 hibát elemezted, aminél szigorúan túlélési alapon mindegy, melyiket használod.
A harmadikban leírtad, hogy 2 hibánál az 10-nak nagyobb az esélye a túlélésre. Ez a 2 konfiguráció között a valódi különbség... (3+ hibánál már nincs adat.)

Ha még most sincs gőzöd, hogy mit szeretnék mondani, akkor elmondom:
Te kijelentetted, hogy az 10 a jobb, (ezzel mellesleg egyetértek) viszont csak a 3. hozzászólásodban fejtetted ki, hogy miért!!! Ketten is rákérdeztünk...
Igaz, hogy 2 sorban is le lehetett volna ezt írni, de tudod én szeretek pontosan, érthetően fogalmazni... (Mellesleg mondtam már, hogy forgalomfüggetlen a netem ? :D )

Utolsó gondolat:

A kérdező RAID01-ől, RAID10-ról, és RAID6-ról beszélt.
Fontossági sorrendben:
- Redundancia (vagy inkább adatbiztonság) : RAID6 ≈ RAID10, RAID01
- Teljesítmény (figyelembe véve a rebuild időt) : RAID10 ≈ RAID6, RAID01
- Méret (segítség) : RAID01 = RAID10 = RAID6

Valójában eldöntötte a RAID10-át. Mi csak elmélkedtünk róla... :D

PEACE!!! És tényleg nem veszekedni akartam !!!

--
Debian Linux rulez... :D

Még pár gondolat anélkül, hogy ismerném a helyzeted:

- Egy rebuild még mindig jobb, mint egy teljes adatvesztés.
- Egy kicsit lassabb rendszer még mindig jobb, mint egy nem működő.
- Ha azok, akik a fizetésedet adják, nyüsszögnek, mert valami lassú, akkor talán közölni kellene velük, hogy költeni is kellene egy jobb, nagyobb rendszerre. A tájékoztatás elmulasztása a te hibád!
- Ha ennyire nagy a rendszer, akkor fontos is, és ezért is kell rá költeni, és fognak is rá költeni!
- Ha ennyire nagy a rendszer, akkor maga a rendszer a SPOF!!! A rendszer redundanciáját biztosítani kell!!!
- Mindent el kell követni, hogy olyan rendszer legyen kiépítve, ami nem ad arra okot, hogy a fizetésedet adók nyüsszöghessenek! (Pl. RAID10 :D)
- Ha ezek ellenére, ezek figyelembevétele mellett is van nyüszi, akkor nem te vagy a felelős/hibás...

--
Debian Linux rulez... :D

Az a vilagon senkit nem erdekel, hogy nem te vagy a felelos. Egyszer csak azt veszed eszre, hogy a kezedbe nyomtak a kiskonyvet. Es onnantol kezdve a boltos neni nem fogja megerteni, hogy te ezert nem voltal felelos meg azert sem voltal felelos.

A tobbi gondolatbol csak nehanyra reagalnek:
"Ha ennyire nagy a rendszer, akkor fontos is, és ezért is kell rá költeni, és fognak is rá költeni!"
Ezt ne vedd keszpenznek. Bankok fejesei ragjak az otforintost ha gepcsere van.
"Ha ennyire nagy a rendszer, akkor maga a rendszer a SPOF!!! A rendszer redundanciáját biztosítani kell!!!"
Ez latod igaz. Viszont altalaban a backup rendszer szokott a kisebb teljesitmenyu lenni, eppen azert, mert backup, es nem megy rajta terheles 7/24-ben. Es ha valami lassabb, akkor az ugyfeleid fognak nyusszogni, a fonokod az inkabb ordibalni fog. Es a vilagon mindenki (foleg az ugyfelek) le fogja sz*ni magasrol, hogy te nem tehetsz rola. Ha meg van teljesitmenyben jobb valasztasod is (ami tehat kisebb lassu idoszakot eredmenyez), akkor maris a te hibad, hogy nem azt valasztottad.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Totál egyetértek veled!

Viszont szerintem nem tartunk ott, hogy ha rossz egy munkahely, akkor erőszakkal ott tartanának bárkit. És azért az IT nem egy olyan szakma, ahol ne lehetne állást találni. Persze nem könnyű, és sokan nem is mernek váltani. Saját tapasztalatom, hogy max. 3 hónap alatt lehet találni egy új helyet, ami - megint tapasztalat - sokkal jobb, mint a régi.

Ne vegyétek magatokra, de valahol azt érzem, hogy az IT területén dolgozók (és tisztelet a kivételnek) tényleg a tipikus "geek" fajták, akik nagy keretes szemüvegben ülnek egy számítógép monitorja mögött, és szinte összeomlanak, ha rájuk szól valaki... :D

Szerintem ha szólsz a főnöködnek, hogy baj lehet a nem megfelelő infrastruktúra miatt, és ennek ellenére sem fejleszt, akkor nincs "joga" kirúgni téged egy adott rendszerhiba esetén.
Most komolyan, van akit ezért rúgtak ki? Vagy inkább csak félünk ettől a lehetőségtől?

Persze, hogy "rágják az ötforintost", viszont azt gondolom te is tudod, ha valamire nem költenek, akkor az lemarad a fejlődésben/elromlik/elavul/stb. Tehát valahol rá lesznek kényszerítve a beruházásra, és ezért írtam, hogy fognak rá költeni. (Ha tetszik, ha nem.)

A backup témát nem igazán értem. Lehet backup-olni adatokat, ami adatbiztonság. Lehet backup-olni adatokat+szolgáltatásokat, ami inkább az elosztott rendszerek irányába mutat. Ahogy írtam, még mindig jobb egy lassabb rendszer, mint egy nem működő. Figyelembe kell venni mindenkinek, hogy bizony néha előfordulnak meghibásodások, és akkor a teljesítmény kisebb mint máskor.

De igazán az lenne a kérdésem, hogy akkor te mit tennél, mit javasolnál?
Hogyan kell egy rendszert felépíteni?
Mindig csak hagyni, hogy a "hozott anyagból" lehessen dolgozni?

--
Debian Linux rulez... :D

"A backup témát nem igazán értem."

jelen esetben: backup == tartalék

egyébként tényleg ne feszegesd az üzemeltetést, mert látszik, hogy nincs sok tapasztalatod komolyabb környezetekben. (Komolyabbnak azt értem, ahol százmilliós tételnél kezdődik az infrastruktúra értéke, és konvergál végtelen felé...)

Az IT területen dolgozókat felesleges tipizálni. Geek-eket meg pl. nagy cégeknél keveset látsz. Egy jelentős részük csak arra jó pl. hogy felhívja a supportost, ha valami gond van. (Ez néha nem is baj, mert nagy elbaszások vannak, amikor pl. a SOHO linux geek beszabadul egy nagyobb rendszerre, aztán nekiáll "megcsinálni" a dolgokat.)

A döntéshozatalkor az elsődleges szempont a gazdasági. Annyi pénz soha nincs, hogy az a konfig kerüljön megvalósításra, amit a szakember mond. (Egyébként a szakemberek elég gyakran hajlamosak is irreálisan túlméretezni, és túlbiztosítani a dolgokat.)
A kirúgás extrém eset, de ha valami tervezési hiba miatt lassú, akkor is az üzemeltetőt baszogatják. Igen azt megteheti, hogy széttárja a karját , és azt mondja, hogy ő szólt. Kb. a 3. esetnél már nyomják is a kezébe a munkakönyvét. Bár az álltalános eset, hogy magától húz el, mert nem bírja a stresszt.

"Hogyan kell egy rendszert felépíteni?"
Rendszert felépíteni nem nagy kunszt, ha jól meg van tervezve.
A tervezés már érdekesebb. Meg kell pl. határozni az elvárásokat, ami az egyik fő buktatója a dolognak. Amíg az eszközök kiválasztása hasonló a legózáshoz (a meglévő ismert elemekből állítod össze), addig az elvárások meghatározása kevésbé egzakt. Gyakran napokig, vagy hetekig mérni és elemezni kell. Ez leginkább meglévő rendszerek átalakításánál/migrációjánál igaz.

stb,stb,stb... több könyvet is megírtak már a témában, tényleg nem egy Raid verziókról szóló topicban kellene ezt elemezni.

Agreed.

Tényleg nagyon elmentünk a topic témájától (hála nekem :D).
Tényleg nem dolgoztam a te olvasatodban komolyabb környezetben. Náluk csak pár 10 milla az IT.
Igen, tapasztaltam már én is SOHO linux geek beszabadulást :D Na meg persze én is valahol azon a szinten kezdtem. (Talán nem nagyképüség, hogy már nem tartom magam SOHO szintűnek.)
A gazdasági szempont mindig fontos, és igen, gyakran hajlamosak az IT-sek túlbiztosítani rendszereket. Én próbálok az arany középúton navigálni.

Tényleg, ne nyissunk egy üzemeltető topicot ??? :D (Csak vicc.)

--
Debian Linux rulez... :D

Tudod, amikor harom honapig 30 ezer forintbol kell kifizetned 60-at, es kozben meg enned is kell, ketszer is meggondolod, utcara kerulj-e. Nem mindenkinek van apuci-anyuci, hogy a gondjat viselje, amig epp nincs munkaja.

Nincs "joga" kirugni... hat igen. Az a baj a fene erkolcsi jogokkal, hogy nem irott szabalyok, es ettol fuggetlen kirughat. De igen, felunk is ettol a lehetosegtol, mert most nem kapkodnak az uj emberek utan.

Ha elromlik, es nem mukodik tovabb az megint mas teszta, mint a fejlesztes. Azt nehezebben emeszti meg a nem IT beallitottsagu managger emberke "Minek ujabb? Ez is mukodik meg nem? Akkor meg?". Tenyleg latvanyos problemaknak kell lenni, hogy a managger feju emberke is megertse, hogy igen, valoban fejleszteni kell, ha nem akarjuk becsukni a boltot.

"Figyelembe kell venni mindenkinek" ... :-D es akkor meg nagyon finom voltam. A valosag az, hogy _nem_ veszik figyelembe, es hoborognek. "A zexplorerben nem jelennek meg a dokumentumaim! - Probalj meg frissiteni - Most megjelentek... most frissitettem, es megint nem... azonnal csinalj valamit!!!!!!". Es ez meg az enyhebb verzio volt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Valamit félreértesz. Én sem poénból keresetem/találtam új állást. És képzeld nekem sincs apuci-anyuci, aki a gondomat viselje. Talán ez is olyan tipikus (nem geek/nem rendszergazda, de) számítógéppel foglalkozó kölyök sztereotípia, amikor azt gondoljuk, hogy önmaguktól életképtelenek az ilyenek. Bár inkább csak velem van a gond. És igen, nagyon sarkítottam.

Szerintem nagyonis szar helyzet, ha mindennap félnem kell attól, hogy kirúghatnak. Én nem szeretnék úgy bemenni dolgozni, hogy azt lessem, mikor tolják elém a "kiskönyvet". Én dolgozni járok, mert szeretem a munkám. És tudod a számok nem hazudnak, míg az ember igen. És miért jó olyan helyen dolgozni, ahol gond van az erkölccsel? Tudom, nem mindenki teheti meg, de azért azt gondolom, hogy erre kellene törekedni, és nem beletörődni a dologba.

Persze, hogy más az üzemeltetés, mint a fejlesztés. Viszont például amikor mi karbantartási szerződéseket kötünk, akkor kikötjük, hogy bár lehet távolról menedzselni szinte bármilyen rendszert, mégis a karbantartónak meg kell nálunk jelennie, mert egy rohadt zörgő ventillátort nem lehet meghallani egy státusz jelentős e-mail-ben. :D Az pedig már egyenes következménye az előrelátó karbantartásoknak, hogy a technikával együtt fejlődést/fejlesztést hozzanak egy rendszerbe. A másik dolog pedig az, hogy egy túlterhelt rendszerből igenis lehet statisztikákat kiszedni, amik már alátámasztják azt, hogy miért kell a fejlesztés.

Érdekes amit mondasz, hogy inkább hörögnek rád. Már ne haragudj, de akkor téged nem becsülnek meg sem szakmailag, sem emberileg. Nálunk ilyen nincs! Természetesen vannak hibák, és főként a Zexplorer és társainál, de ahogy én nem túrok bele más munkájába, úgy ők sem próbálnak rendszergazdásat játszani. Azt azért elfelejtetted, hogy én is a valóságban élek, hús-vér emberek között, akik nálunk megértik, ha valami probléma van. És azt is tudják, hogy ha nagy ritkán gond támad, akkor számíthatnak rám a hiba gyors kijavításában.

Az biztos, hogy nem feladatunk a rendszerek beszerzése, mert az pénzügyi terület/döntés. De mégis a rendszer kialakítása/üzemeltetése/fejlesztése (szakmailag) a mi kötelességünk. Én ebben hiszek.

Persze lehet más véleményetek, amit én elítélni nem akarok, és azt szeretném, ha ti sem ítélnétek el az enyémet.

--
Debian Linux rulez... :D

( KisLebowszky | 2009. 06. 08., h – 15:51 )

1. LVM-el hozzáfűzni a kettőből kialakított raid1-et.
2. újraépíteni, és raid5öt csinálni. Ott csak n-1 a veszteség (persze ha ugyanolyan méretűek)

---MacOsX10.5, MB---

( turdus | 2009. 06. 08., h – 22:14 )

"redundancia szempontjából a raid0+1-nek felel meg."
Na, ne keverjük. A raid1+0 jó dolog, a raid0+1 meg baromság.

( apal v | 2009. 06. 08., h – 23:22 )

A fontossági sorrend: redundancia, teljesítmény, ...
raid6
A fontossági sorrend: teljesítmény, redundancia, ...
raid10

raid6: + e'rv me'g: egyszeru bovithetoseg.

( takemeaw | 2009. 06. 09., k – 23:52 )

Adott egy kis fájlszerver két hdd-vel szoftveres raid1-ben összefűzve. Van két elfekvő hdd

4 disk eseten a raid6 vajon mi?

2 parity meg 2 adat? -> ugyanannyi a terulet ami a rendelkezesre all mint raid 10-nel

a terulet ugyanannyi, a redundancia viszont raid10-nel nem teljes (azaz nem igaz, hogy tetszoleges ke't diszk tonkremehet adatvesztes nelkul). egy nagyobb me'ret eseten (mikor sok-sok ora/nap a szinkronizalas, foleg ha kozben a vasat is hasznaljak) izgalmas, hogy az elso tonkrement diszk csereje+szinkronizalasa kozben melyik masik mehet esetleg tonkre...

( Proci85 v | 2009. 07. 29., sze – 00:06 )

2db raid 1, majd raid0-ban össszehúzni ahogy Te is irod.

( Esc | 2009. 07. 31., p – 08:38 )

Használj inkább raid7-et.
4 disk esetén, ha három és fél kiesik akkor is megmaradnak az adataid és a leggyorsabb raid típus.:)