RAID-tervezes (16 diszkkel)
KORN Andras
Sziasztok,
hamarosan lesz egy uj gepem, 16 darab masfel terabyte-os SATA diszkkel. A
vilag minden bizonnyal egyik legnagyobb Subversion repositoryja lesz rajta
(tekintsunk most el attol a kerdestol, hogy tenyleg a Subversion-e a
legjobb verziokoveto rendszer erre a celra).
Azon gondolkodom, milyen RAID-elrendezest lenne erdemes csinalni es miert.
Szerintetek?
Kb. 6-8TB netto kapacitasra van szukseg, meg persze redundanciara, ugyhogy
eleg tagak a lehetosegek; a cel az, hogy minel gyorsabb legyen, es mondjuk
barmely ket diszk egyideju kieseset mindenkeppen kibirja ugy, hogy nem
szamottevo a bithibak elofordulasi valoszinusege helyreallitas alatt. A
diszkekre 10E-14-es bithibaratat iger a gyarto.
Az alaplap egy Supermicro X8DTH-6F lesz, amin van egy LSI 2008 8-portos
SAS-vezerlo; ez RAID0-at, RAID1-et es RAID10-et tud (ami minden bizonnyal
RAID0 over RAID1, tehat nem a linuxos RAID10). 8 diszk ezen fog logni. Van
meg 6 alaplapi SATA2 port (az ICH10R-en); erre megy masik 6 diszk. A maradek
ketto egy Silicon Image chipes PCIe-s kartyan log majd.
Hatmagos Xeon DP X5650 CPU lesz a gepben es 8GB RAM.
Elso megkozelitesben azt gondolnam, hogy a hardveres RAID nagyjabol
kizarhato, es amugy is orulnom kell, ha az LSI vezerlo hajlando normalisan
mukodni a desktop diszkekkel. (Az LSI-vel tudnek csinalni egy 6TB-os
hardveres RAID10-et, de az csak pontosan egy diszk kieseset birna ki
biztosan, ugyhogy ha folotte nem RAID1-et vagy linuxos RAID10-et csinalok,
akkor a redundancia nem elegendo.)
Nezzuk a szoftveres lehetosegeket.
1. Csinalhatnek egyetlen nagy RAID6-tombot. A netto kapacitas 21TB lenne.
Ket diszk kieseset tulelne; a helyreallitashoz viszont 21TB-ot kene hiba
nelkul vegigolvasni, ami 10E-14-es bithibarataval remenytelennek tunik (a
hibak szamanak varhato erteke majdnem 2; annak a valoszinusege, hogy lesz
hiba, kb. 81%).
2. Csinalhatnek ket RAID6-tombot, 8-8 diszkbol, es ezek folott RAID0-at. A
netto kapacitas 18TB lenne; barmely ket diszk kieseset kibirna (szerencses
esetben akar negyet is); egy-egy RAID6-os tomb helyreallitasahoz 9TB-ot kene
vegigolvasni, ami kb. 51% esellyel nem sikerulne. Ez esetleg bevallalhato
(mivel feltehetoen csak kiveteles esetben fordul elo, hogy ket diszk
egyszerre romlik el, amugy meg hamar cserelnem a kidolo diszkeket).
3. Csinalhatnek az egeszbol egy nagy (linuxos) RAID10-et, mindenbol 3
peldanyt tarolva. A netto kapacitas 8TB lenne, ami az elfogadhato also
hatar. Ket diszk kiesese eseten a helyreallitas kb. 47% esellyel sikertelen
bithiba miatt.
4. Csinalhatnek 4 darab, egyenkent 4 diszkbol allo RAID5-tombot, es ezek
folott ujabb RAID5-ot. Netto kapacitas: 13.5TB. Ez is kibirja ket diszk
kieseset, csak kb. 66% esellyel nem lehet utana helyreallitani.
5. 4 RAID5 folott RAID10, ket masolattal. 9TB netto kapacitas, 51% esely a
bithibara helyreallitas kozben.
6. 3 darab otdiszkes RAID5 folott RAID10, ket masolattal (+1 hotspare).
Szinten 9TB netto kapacitas, szinten 51%.
7. 8 RAID1 folott RAID5. 10.5TB netto kapacitas, ~57%.
8. Egyeb.
A fentiek mindegyikeben kozos (szerintem), hogy egy diszk kiesese eseten meg
elhanyagolhato (a hardver altal detektalt) bithiba miatti
helyreallithatatlansag valoszinusege.
Az egymasba agyazott RAID-szintek elonye latszik lenni, hogy jobban
kihasznaljak a tobb CPU-magot (a CONFIG_MULTICORE_RAID456-tal eleg rossz
tapasztalataim voltak; konkretan rettento lassu volt).
Azt nem igazan tudom eldonteni, hogy a valosagban vajon melyik a leggyorsabb
a fentiek kozul (valoszinuleg a 3-as, de az a helypazarlas miatt nem annyira
szimpatikus). Melyiket valasszam es miert?
A kovetkezo kerdes az, milyen filerendszert tegyek ra, ill. hogy mekkora
chunksize-t allitsak be az egyes RAIDeken. Kb. 6-8 konkurens felhasznalora
szamitok, tehat erdemes lehet viszonylag chunkokat hasznalni, hogy egymastol
fuggetlenul dolgozhassanak a diszkek, gondolom en. Az egymasba agyazott
RAIDeknel viszont mar nem igazan tudom eldonteni, melyiknek mekkorak
legyenek a chunkjai.
A "milyen filerendszert" kerdesre a zsigeri valaszom az xfs lenne, de talan
van jobb; pl. probalta mar valaki elesben valamelyik linuxos
zfs-megvalositast? Abban az integritasvedelem meg a RAID-Z tunik
szimpatikusnak.
Koszi
Guy
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
Define (n.) De ting you get for breaking de law.
_______________________________________________
linux++ mailing list
lin...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux++
Pallai Roland
Szia,
KORN Andras <korn-l...@elan.rulez.org> írta (2010. október 17. 2:04):
> A kovetkezo kerdes az, milyen filerendszert tegyek ra, ill. hogy mekkora
> chunksize-t allitsak be az egyes RAIDeken. Kb. 6-8 konkurens felhasznalora
> szamitok, tehat erdemes lehet viszonylag chunkokat hasznalni, hogy egymastol
> fuggetlenul dolgozhassanak a diszkek, gondolom en. Az egymasba agyazott
> RAIDeknel viszont mar nem igazan tudom eldonteni, melyiknek mekkorak
> legyenek a chunkjai.
Gyanítom sok apró I/O lesz a Subversion miatt, emiatt én semmiképp nem
mennék 32-64KB fölé ha RAID{5,6} lesz a képben.
Mivel a szerver nem tűnik gyárinak, nekem néhány hardverrel
kapcsolatos tanácsom lenne. A legfontosabb kérdés az adatbiztonság
szempontjából, hogy a winyók milyen tápra lesznek bekötve. Átalakítót,
elosztót semmiképp se használj, mert ha "kontakos" lesz, akkor a winyó
eldobálja a writeback cache tartalmát úgy, hogy közben talán észre
veszed (egy brownout a földön nem jelez SATA disconnect eseményt, ha
nincs aktív IO akkor timeout se látszik). Ez azért nagyon veszélyes,
mert a a winyó nem esik ki a raid-ből, lyukkal a hasában megy tovább a
fájlrendszer és a további írással a hiba továbbgyűrűzik a többi
winyóra is, úgy teszi használhatatlanná a fájlrendszert, hogy dmesg
-ben semmi hardware hibát nem látsz (ez remek táptalaja sok
adatvesztéses történetnek).
Ha ezt kikapcsolt writeback cache -el akarod elkerülni, akkor
brutálisan csökken a teljesítmény, ha barriers -el, akkor nagyon meg
kell fontolni, hogy hogy kombináld össze a RAID -et és milyen kernelt
használj, ha backplane-el, akkor az egy jó döntés. :)
Ha PC kategóriás a házba szerelsz, akkor mindenképp {4,5}-in-3 hotswap
cage -el építsd be a winyókat, mivel azokon redundáns SATA betáp van,
egy csatlakozó oxidációja még nem okoz kiesést, a backplane és a winyó
között lévő csata csatlakozó pedig nem olyan vészes (az "AT" avagy
"MOLEX" csatlakozó a főgonosz).
Másik probléma a desktop winyókkal a writeback cache -el kapcsolatban,
a firmware stabilitása. Sajnos egyes típusok néha megfagynak és
resetelik magukat, dobva a writeback cache -t. Ebben az a jó, hogy
általában IO közben resetelnek és akkor legalább kapsz egy timeout
hibát, a rossz, hogy ez általában nem látszik a SMART -on. Míg az
előbb említett tápkiesés pörgeti a SMART 4 -es és 192 -es számlálóit,
addig a firmware reset csöndben lezajlik (most egy Samsung HD204UI 2TB
van a kezem alatt ami szintén ilyen). A desktop piacra szánt nyomott
árú SATA winyók között sajnos zsákbamacska a választás. Érdemes
először 2-4db -ot venni és egy hétig teljes terhelés alatt pörgetni
mély NCQ -val többféle vezerlőn - ha bírják, jöhet a többi.
Az utóbbi években elég sok "tákolt", de nagyteljesítményű
storage-szervert üzemeltettem, az adatvesztések jelentős részet a
fenti jelenségek okozták. Az igazi, klasszikus winyóhalál (amikor
megáll és megmakkan) ritka, szóval szinte nulla a gyakorlati esélye
annak, hogy 16 winyóból 2 meghaljon a spare rebuild előtt - feltéve,
hogy azonnal cseréled. A gyakorlati tapasztalataim alapján én 2x8 -as
RAID6 -ot tennék és a hardware összerakására, winyók kiválasztására,
illetve a SMART monitoringra fordítanék nagy figyelmet.
Ha gyári backplane -el van felvértezve a ház, akkor bocs a szófosásért. :)
PÁSZTOR György
Szia,
"KORN Andras" <korn-l...@elan.rulez.org> írta 2010-10-17 02:04-kor:
> A "milyen filerendszert" kerdesre a zsigeri valaszom az xfs lenne, de talan
> van jobb; pl. probalta mar valaki elesben valamelyik linuxos
> zfs-megvalositast? Abban az integritasvedelem meg a RAID-Z tunik
> szimpatikusnak.
Van valamilyen különösebb okod, hogy ne valamelyik OSol-utód rendszert tedd
rá? (Azon kívül, hogy linuxos listán kérdezel a raid elrendezésről :-D)
Bonnie++-al én méregettem b134-en. raidz2 + hw-es raid6 is egész használható
tud lenni, szóval én a 2. elrendezést választanám (2x8raid6).
Vagy egy 3.-at: 2 disk raid1-ben az OS-nak, és a maradékból pl. a 6 ich-n
levőből egy raidz2 és a 8 lsi porton levőből egy másik raidz2. Ez utóbbi
raidz2 persze lehet egy poolban.
Üdv:Gyur!
HAJDU Csaba
On Sun, 17 Oct 2010, Pallai Roland wrote:
> Ha gyári backplane -el van felvértezve a ház, akkor bocs a
> szófosásért. :)
Gondolom, a Supermicro alaplaphoz Supermicro haz lesz,
azokkal nincs ilyen gond.
A kettos diszkhalal szerintem is nagyon valoszinutlen,
foleg, ha folyamatosan megy a gep. Nalunk foleg 1 es 2 TB-s
Hitachik vannak, nincs veluk semmi gond.
Egyebkent miert nem 2 TB-s diszkeket veszel a 1.5-osek
helyett? Akkor nem kene harmadik kontroller, olcsobb es/vagy
nagyobb is lehetne az egesz, stb.
KORN Andras <korn-linux++@elan.rulez.org> kezdo kerdesek nelkul
Koszi a valaszokat; egyben valaszolok mindre.
On Sun, Oct 17, 2010 at 03:10:16AM +0200, Pallai Roland wrote:
> KORN Andras <korn-l...@elan.rulez.org> írta (2010. október 17. 2:04):
> > A kovetkezo kerdes az, milyen filerendszert tegyek ra, ill. hogy mekkora
> > chunksize-t allitsak be az egyes RAIDeken. Kb. 6-8 konkurens felhasznalora
> > szamitok, tehat erdemes lehet viszonylag chunkokat hasznalni, hogy egymastol
Itt kimaradt az, hogy "nagy".
> > fuggetlenul dolgozhassanak a diszkek, gondolom en. Az egymasba agyazott
> > RAIDeknel viszont mar nem igazan tudom eldonteni, melyiknek mekkorak
> > legyenek a chunkjai.
> Gyanítom sok apró I/O lesz a Subversion miatt, emiatt én semmiképp nem
> mennék 32-64KB fölé ha RAID{5,6} lesz a képben.
En azt kepzelem, hogy joval kevesebb iras, mint olvasas lesz, es ezert
megerheti a nagyobb chunkmeret (nem kell annyi read-modify-write).
> Mivel a szerver nem tűnik gyárinak, nekem néhány hardverrel
> kapcsolatos tanácsom lenne. A legfontosabb kérdés az adatbiztonság
> szempontjából, hogy a winyók milyen tápra lesznek bekötve. Átalakítót,
> elosztót semmiképp se használj, mert ha "kontakos" lesz, akkor a winyó
Supermicro haz lesz, backplane-nel, szoval ez talan nem akkora veszely.
> Ha ezt kikapcsolt writeback cache -el akarod elkerülni, akkor
> brutálisan csökken a teljesítmény, ha barriers -el, akkor nagyon meg
> kell fontolni, hogy hogy kombináld össze a RAID -et és milyen kernelt
> használj, ha backplane-el, akkor az egy jó döntés. :)
A barrier vagy a kikapcsolt writeback cache mindenkeppen kell, nem? Az
#xfs-en azt tanacsoltak nekem (egy masik problema kapcsan), hogy softraid 6
eseten inkabb kapcsoljam ki a writeback cache-t es hasznaljam a nobarrier
mount-opciot, mert a raid6 barrier-emulacioja nagyon lassu. Kimerni nem
mertem ki, de szubjektive nem lett gyorsabb tole...
> Másik probléma a desktop winyókkal a writeback cache -el kapcsolatban,
> a firmware stabilitása. Sajnos egyes típusok néha megfagynak és
> resetelik magukat, dobva a writeback cache -t. Ebben az a jó, hogy
Huh. Ezzel eddig nem talalkoztam, de ha igy van, akkor muszaj kikapcsolni a
writeback cache-t, nem?
> általában IO közben resetelnek és akkor legalább kapsz egy timeout
> hibát, a rossz, hogy ez általában nem látszik a SMART -on. Míg az
> előbb említett tápkiesés pörgeti a SMART 4 -es és 192 -es számlálóit,
> addig a firmware reset csöndben lezajlik (most egy Samsung HD204UI 2TB
> van a kezem alatt ami szintén ilyen). A desktop piacra szánt nyomott
> árú SATA winyók között sajnos zsákbamacska a választás. Érdemes
> először 2-4db -ot venni és egy hétig teljes terhelés alatt pörgetni
> mély NCQ -val többféle vezerlőn - ha bírják, jöhet a többi.
Erre sajnos nincs ido; teljesitmenyt meregetni se nagyon lesz (2-3 felallast
esetleg meg ossze tudok hasonlitani, de atfogo meressorozat semmikeppen nem
fer bele).
A diszkek amugy valoszinuleg (sajnos) Seagate Barracuda LP-k lesznek (azert
sajnos, mert ezek csak 5900rpm-en forognak); ha sikerul atvarialni, akkor
7200.12-es Barracudak.
> hogy azonnal cseréled. A gyakorlati tapasztalataim alapján én 2x8 -as
> RAID6 -ot tennék és a hardware összerakására, winyók kiválasztására,
> illetve a SMART monitoringra fordítanék nagy figyelmet.
Azt tudja valaki, hogy az LSI 2008-ra dugott vinyokat lehet-e ertelmesen
SMARTolni Linux alol?
Eddig valodi RAID-vezerlobol csak egy Promise SureTrack vagy SuperTrack vagy
ilyesmivel volt dolgom (a stex driver hajtotta), es azon nem "latott at" a
smartctl, a sajat SMART-monitorozasi kepessegei meg eleg gyengecskek voltak.
On Sun, Oct 17, 2010 at 07:24:11AM +0200, HAJDU Csaba wrote:
> Egyebkent miert nem 2 TB-s diszkeket veszel a 1.5-osek
> helyett? Akkor nem kene harmadik kontroller, olcsobb es/vagy
> nagyobb is lehetne az egesz, stb.
Azt remel(t)em, hogy 16 diszkkel gyorsabb tud lenni, mint kevesebbel, a
spindle-k szamanak novekedese miatt.
On Sun, Oct 17, 2010 at 03:36:31AM +0200, PÁSZTOR György wrote:
> "KORN Andras" <korn-l...@elan.rulez.org> írta 2010-10-17 02:04-kor:
> > A "milyen filerendszert" kerdesre a zsigeri valaszom az xfs lenne, de talan
> > van jobb; pl. probalta mar valaki elesben valamelyik linuxos
> > zfs-megvalositast? Abban az integritasvedelem meg a RAID-Z tunik
> > szimpatikusnak.
>
> Van valamilyen különösebb okod, hogy ne valamelyik OSol-utód rendszert tedd
> rá? (Azon kívül, hogy linuxos listán kérdezel a raid elrendezésről :-D)
Igen; azokhoz nem ertek es most nincs ido megtanulni (a Subversionon kivul
lesz a gepen mas dolog is, vserverekben, ugyhogy a teljes osszetettseg
meghaladja azt a szintet, aminek nekivagnek a keves solarisos tapasztalatom
birtokaban).
Az esetleg szoba johetne, hogy opensolarisos storage-szervert csinaljak a
gepbol es egy masik gep legyen az svn-szerver, ami nfs-sel hasznalja emezt,
de nem hiszem, hogy megeri.
> Bonnie++-al
Az szerintem nem sokat er; dontoen egyszalu, es teljesen mesterseges
(szintetikus) terheles. Az iozone vagy a postmark szerintem jobb, de pl. egy
iozone-os meres egynapos (vagy meg nagyobb lelegzetu) projekt, es akkor az
eredmenyek ertelmezeset meg el se kezdtuk. :)
> én méregettem b134-en.
Az micsoda?
> raidz2 + hw-es raid6 is egész használható
> tud lenni, szóval én a 2. elrendezést választanám (2x8raid6).
Azt amugy jol gondolom, hogy a zfs csak tobbszorozni tudja az adatot (ill.
az integritasellenorzes miatt bizonyos mertekig hibajavitasra is kepes), de
RAID5/RAID6-szeru mukodes nincs benne? Tehat olyan, amitol fixen egy vagy
ket diszk halalat kibirja akkor is, ha nem tarol mindnet ketszer vagy
haromszor?
> Vagy egy 3.-at: 2 disk raid1-ben az OS-nak, és a maradékból pl. a 6 ich-n
> levőből egy raidz2 és a 8 lsi porton levőből egy másik raidz2. Ez utóbbi
> raidz2 persze lehet egy poolban.
En amugy particionalnam a diszkeket es az egyes particiokbol csinalnek
kulonbozo RAID-eket, nem az egesz diszkekbol.
Pl. a rendszert egy picike (par gigabyte-os) RAID10-re raknam, amiben minden
haromszor van meg.
Mondjuk a nagy Subversionnek alighanem erdemes lenne dedikalt diszkeket
biztositani, hogy massal ne kelljen versenyeznie a fejek pozicionalasaert;
ezt meg ugy is megoldhatom, hogy a rendszert egy olyan RAID1-re rakom,
aminek az egyik laba egy pendrive, a masik/tobbi meg diszkparticio, de a
diszkparticiokat write-mostlynak jelolom, ugyhogy azokat csak akkor bantja,
ha irni kell.
Szerintetek mennyit szamit az, hogy teljesen kulon diszkeken van-e a
Subversiont tartalmazo RAID-tomb? A tobbi cucc elvileg nem lesz i/o-intenziv
(vagy csak burstosen).
Guy
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
Common sense is what tells you that the world is flat.
Pallai Roland
2010/10/17 KORN Andras <korn-l...@elan.rulez.org>:
>> > fuggetlenul dolgozhassanak a diszkek, gondolom en. Az egymasba agyazott
>> > RAIDeknel viszont mar nem igazan tudom eldonteni, melyiknek mekkorak
>> > legyenek a chunkjai.
>> Gyanítom sok apró I/O lesz a Subversion miatt, emiatt én semmiképp nem
>> mennék 32-64KB fölé ha RAID{5,6} lesz a képben.
>
> En azt kepzelem, hogy joval kevesebb iras, mint olvasas lesz, es ezert
> megerheti a nagyobb chunkmeret (nem kell annyi read-modify-write).
Igazabol a nagyobb chunk olvasasnal egy _kicsit_ segit (if
avg(filesize) > chunksz :), de ha jon egy nem-full-stripe-write, akkor
_sokat_ ront (pl atime update, journal append). A nagyobb chunk
gyakran olyan, hogy amit nyersz a réven, elveszted a vámon..
> A barrier vagy a kikapcsolt writeback cache mindenkeppen kell, nem? Az
> #xfs-en azt tanacsoltak nekem (egy masik problema kapcsan), hogy softraid 6
> eseten inkabb kapcsoljam ki a writeback cache-t es hasznaljam a nobarrier
> mount-opciot, mert a raid6 barrier-emulacioja nagyon lassu. Kimerni nem
> mertem ki, de szubjektive nem lett gyorsabb tole...
Ha mar probalgattad, gondolom lattad, hogy komoly teljesitmenyvesztes
van kikapcsolt WB cache -el irasnal. Ha ezt megengedheted magadnak,
akkor mindenkepp jobb kikapcsolni, bar olyankor a tobb fejmozgas
csokkenti az elettartamot. Meg kell alkudni.
>> Másik probléma a desktop winyókkal a writeback cache -el kapcsolatban,
>> a firmware stabilitása. Sajnos egyes típusok néha megfagynak és
>> resetelik magukat, dobva a writeback cache -t. Ebben az a jó, hogy
>
> Huh. Ezzel eddig nem talalkoztam, de ha igy van, akkor muszaj kikapcsolni a
> writeback cache-t, nem?
Igen, ki kell kapcsolni vagy be kell tesztelni a winyot elotte, hogy
stabil-e a firmware. En epp most javitgatom a fajlokat mentesbol egy
RAID6 tombon, amiben 12db Samsung HD204UI van es 31 -es queue_depth
-el resetelget a firmware.. Sajnos mar korabban is jartunk igy, nem
egyedi eset.
>> hogy azonnal cseréled. A gyakorlati tapasztalataim alapján én 2x8 -as
>> RAID6 -ot tennék és a hardware összerakására, winyók kiválasztására,
>> illetve a SMART monitoringra fordítanék nagy figyelmet.
>
> Azt tudja valaki, hogy az LSI 2008-ra dugott vinyokat lehet-e ertelmesen
> SMARTolni Linux alol?
1068E -vel siman megy a SMART -olas, bizz benne hogy a 2008 -ba is
tovabbvittek a jo szokast. :) Kivancsi vagyok egyebkent a
kontrollerrel kapcsolatos tapasztalatokra, mert mi is ezt az LSI
szeriat favorizaljuk.
> En amugy particionalnam a diszkeket es az egyes particiokbol csinalnek
> kulonbozo RAID-eket, nem az egesz diszkekbol.
Ez meghalalja magat amikor winyot vagy vezerlot kell mas tipusura
cserelni. Erdemes 0.1% -ot uresen hagyni a diszk vegen..
KORN Andras
On Sun, Oct 17, 2010 at 02:22:49PM +0200, Pallai Roland wrote:
> 2010/10/17 KORN Andras <korn-l...@elan.rulez.org>:
> >> > fuggetlenul dolgozhassanak a diszkek, gondolom en. Az egymasba agyazott
> >> > RAIDeknel viszont mar nem igazan tudom eldonteni, melyiknek mekkorak
> >> > legyenek a chunkjai.
> >> Gyanítom sok apró I/O lesz a Subversion miatt, emiatt én semmiképp nem
> >> mennék 32-64KB fölé ha RAID{5,6} lesz a képben.
> >
> > En azt kepzelem, hogy joval kevesebb iras, mint olvasas lesz, es ezert
> > megerheti a nagyobb chunkmeret (nem kell annyi read-modify-write).
>
> Igazabol a nagyobb chunk olvasasnal egy _kicsit_ segit (if
> avg(filesize) > chunksz :), de ha jon egy nem-full-stripe-write, akkor
En ugy gondoltam, hogy parhuzamos olvasasoknal segit, mert az egyik chunkot
az egyik diszkrol olvasom, mikozben a masikat a masikrol, tehat nem
szinkronban kell mozgatni a fejeket, mint mondjuk RAID3-nal.
> _sokat_ ront (pl atime update, journal append). A nagyobb chunk
> gyakran olyan, hogy amit nyersz a réven, elveszted a vámon..
Nyilvan noatime-ot hasznalnek; a journalos problema megfontolando. Esetleg
lehetne a journalnak venni egy kulon SSD-t (az xfs tud kulso journalt).
> > A barrier vagy a kikapcsolt writeback cache mindenkeppen kell, nem? Az
> > #xfs-en azt tanacsoltak nekem (egy masik problema kapcsan), hogy softraid 6
> > eseten inkabb kapcsoljam ki a writeback cache-t es hasznaljam a nobarrier
> > mount-opciot, mert a raid6 barrier-emulacioja nagyon lassu. Kimerni nem
> > mertem ki, de szubjektive nem lett gyorsabb tole...
>
> Ha mar probalgattad, gondolom lattad, hogy komoly teljesitmenyvesztes
> van kikapcsolt WB cache -el irasnal.
Igen, de a barrier is lassu...
> > Azt tudja valaki, hogy az LSI 2008-ra dugott vinyokat lehet-e ertelmesen
> > SMARTolni Linux alol?
>
> 1068E -vel siman megy a SMART -olas, bizz benne hogy a 2008 -ba is
> tovabbvittek a jo szokast. :) Kivancsi vagyok egyebkent a
> kontrollerrel kapcsolatos tapasztalatokra, mert mi is ezt az LSI
> szeriat favorizaljuk.
Jo, megirom majd ide, ha lesz valami emlitesre melto.
Guy
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
Fortress (n): a female fort.
Gabor Gombas <gombasg@digikabel.hu> kezdo kerdesek nelkul
On Sun, Oct 17, 2010 at 02:22:49PM +0200, Pallai Roland wrote:
> 1068E -vel siman megy a SMART -olas, bizz benne hogy a 2008 -ba is
> tovabbvittek a jo szokast. :)
Hat az 1068E kapcsan inkabb arra emlekszem, hogy ket kezzel dobalta el a
diszkeket, ha az ember megkuldte oket SMART parancsokkal. 2.6.35-ben
javitottak.
Gabor
Andras HORVATH
KORN Andras <korn-l...@elan.rulez.org> wrote:
>
> A "milyen filerendszert" kerdesre a zsigeri valaszom az xfs lenne, de talan
> van jobb; pl. probalta mar valaki elesben valamelyik linuxos
> zfs-megvalositast? Abban az integritasvedelem meg a RAID-Z tunik
> szimpatikusnak.
Az enyem is az XFS lenne, hacsak nem akarsz slowlarist (nexentat,
nyilvan :).
BTW, btrfs-t (apropo integritasvedelem) hasznal valaki?
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Andras HORVATH
KORN Andras <korn-l...@elan.rulez.org> wrote:
>
> Az alaplap egy Supermicro X8DTH-6F lesz, amin van egy LSI 2008 8-portos
> SAS-vezerlo; ez RAID0-at, RAID1-et es RAID10-et tud (ami minden bizonnyal
> RAID0 over RAID1, tehat nem a linuxos RAID10). 8 diszk ezen fog logni. Van
> meg 6 alaplapi SATA2 port (az ICH10R-en); erre megy masik 6 diszk. A maradek
> ketto egy Silicon Image chipes PCIe-s kartyan log majd.
FWIW, Supermicroeknak van SAS expanderes backplane-je, 16-24 diszk jol
elvan egy 4 portos SAS (nalam jellemzoen adaptec, YMMV) kartyan.
A masfel TB-s diszkek desktop diszkek?..
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________
KORN Andras <korn-linux++@elan.rulez.org> kezdo kerdesek nelkul
On Sun, Oct 17, 2010 at 11:32:58AM +0200, KORN Andras wrote:
> > raidz2 + hw-es raid6 is egész használható
> > tud lenni, szóval én a 2. elrendezést választanám (2x8raid6).
>
> Azt amugy jol gondolom, hogy a zfs csak tobbszorozni tudja az adatot (ill.
> az integritasellenorzes miatt bizonyos mertekig hibajavitasra is kepes), de
> RAID5/RAID6-szeru mukodes nincs benne? Tehat olyan, amitol fixen egy vagy
> ket diszk halalat kibirja akkor is, ha nem tarol mindnet ketszer vagy
> haromszor?
Termeszetesen rosszul gondoltam: a RAID-Z, RAID-Z2 es RAID-Z3 egyszeres,
ketszeres ill. haromszoros paritast valosit meg.
Guy
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
Sado-masochism means not having to say you are sorry.
KORN Andras <korn-linux++@elan.rulez.org> kezdo kerdesek nelkul
On Mon, Oct 18, 2010 at 07:43:50AM +0000, Andras HORVATH wrote:
> > Az alaplap egy Supermicro X8DTH-6F lesz, amin van egy LSI 2008 8-portos
> > SAS-vezerlo; ez RAID0-at, RAID1-et es RAID10-et tud (ami minden bizonnyal
> > RAID0 over RAID1, tehat nem a linuxos RAID10). 8 diszk ezen fog logni. Van
> > meg 6 alaplapi SATA2 port (az ICH10R-en); erre megy masik 6 diszk. A maradek
> > ketto egy Silicon Image chipes PCIe-s kartyan log majd.
>
> FWIW, Supermicroeknak van SAS expanderes backplane-je, 16-24 diszk jol
> elvan egy 4 portos SAS (nalam jellemzoen adaptec, YMMV) kartyan.
>
> A masfel TB-s diszkek desktop diszkek?..
"Termeszetesen".
Guy
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
For Sale: parachute, used once, never opened, small stain.
Pallai Roland
Gabor Gombas <gom...@digikabel.hu> írta (2010. október 17. 23:17):
> On Sun, Oct 17, 2010 at 02:22:49PM +0200, Pallai Roland wrote:
>
>> 1068E -vel siman megy a SMART -olas, bizz benne hogy a 2008 -ba is
>> tovabbvittek a jo szokast. :)
>
> Hat az 1068E kapcsan inkabb arra emlekszem, hogy ket kezzel dobalta el a
> diszkeket, ha az ember megkuldte oket SMART parancsokkal. 2.6.35-ben
> javitottak.
Igen, ezzel valamikor régen találkoztam, de szerintem a Debian
backportolta a fixet a Lenny -be is, mert most minden 106[48] -as
csöndben működik SMART -al, nem kell hozzá gányolni.
Papp Tamás
On 2010.10.18. 9:40, Andras HORVATH wrote:
> KORN Andras<korn-l...@elan.rulez.org> wrote:
>> A "milyen filerendszert" kerdesre a zsigeri valaszom az xfs lenne, de talan
>> van jobb; pl. probalta mar valaki elesben valamelyik linuxos
>> zfs-megvalositast? Abban az integritasvedelem meg a RAID-Z tunik
>> szimpatikusnak.
> Az enyem is az XFS lenne, hacsak nem akarsz slowlarist (nexentat,
> nyilvan :).
>
> BTW, btrfs-t (apropo integritasvedelem) hasznal valaki?
btrfs-t igen, de egyelore csak nagyon alap modon (mkfs && mount).
Eddig nem okozott semmi problemat, kopp-kopp.
Egyebkent virtualis gepek futnak rajta, lxc es kvm image-ek.
udv,
tamas
Gabor HALASZ
On 2010.10.17. 3:10, Pallai Roland wrote:
> a firmware stabilitása. Sajnos egyes típusok néha megfagynak és
> resetelik magukat, dobva a writeback cache -t. Ebben az a jó, hogy
> általában IO közben resetelnek és akkor legalább kapsz egy timeout
> hibát, a rossz, hogy ez általában nem látszik a SMART -on.
Az ilyesmit hogyan detektalod/teszteled?
--
Gabor HALASZ <hala...@freemail.hu>
Pallai Roland
2010/10/19 Gabor HALASZ <hala...@freemail.hu>:
> On 2010.10.17. 3:10, Pallai Roland wrote:
>> a firmware stabilitása. Sajnos egyes típusok néha megfagynak és
>> resetelik magukat, dobva a writeback cache -t. Ebben az a jó, hogy
>> általában IO közben resetelnek és akkor legalább kapsz egy timeout
>> hibát, a rossz, hogy ez általában nem látszik a SMART -on.
>
> Az ilyesmit hogyan detektalod/teszteled?
badblocks -w
Amikor kicsit komolyabban beleástam magam a problémába, akkor a libata
-ból kiütöttem az automata sata reset-et hiba után (helyette
elpánikolt a kernel) és systemtap -al loggoltam az NCQ műveleteket,
hogy meg tudjam vizsgálni mi a fene történik. Azt találtam, hogy
egy-egy timeout hiba után a diszken több MB -nyi olyan adat mutatta az
írás előtti állapotát amire a diszk már visszaválaszolt, hogy kiírva.
Azt már igazából nem kutattam, hogy a winyó firmware -je mit csinál
ilyenkor, csak tippelek hogy valamiféle reset zajlik le, amiatt nem
kerül kiírásra a WB cache..
Sajnos még nem volt időm egy komplett dolgozatot összehozni a témáról,
ahhoz ennél jóval több tesztet kéne elvégezni, de engem ez már
meggyőzött arról, hogy a jelenség létezik.
A jó hír, hogy azon a 2 típuson, ami eddig reprodukálhatóan mutatta a
hibát, csak akkor jelzett hibát a "badblocks -w", ha a dmesg -ben is
jött timeout/reset üzenet a winyóról, szóval közvetetten lehet
detektálni.