diskove pole pro webhosting

[Jan Kasprzak]

Michal Krajčírovič wrote:
: Ext3 mi prijde jako degradace vykonu toho pole celeho

	Proc? Pokud tam nebudete delat operace na ktere jsou explicitne
stavene lepe jine FS (zapis velkeho bloku dat najednou, cteni tehoz,
mozna > 10k souboru v jednom adresari), tak by ext3 nemelo byt vyrazne
pomalejsi. Za to vyrazne dobre proverene (e2fsck ma dost extenzivni
test suite, obcas mu zkouseji i predhodit umele vygenerovane nahodne
porusene filesystemy, aby neco neprehledli).

	Ad vykon: neco jineho je co namerite pres bonnie nebo iozone,
a neco jineho je kdyz se ty pristupy rozlozi pres 3000 domen.

	Momentalne asi zadny jiny FS nez ext3 nema ordered mod, takze pri
havarii systemu mate problem, ze v souborech ktere v te dobe zvetsujete
zustanou nuly nebo jeste hure nahodna/cizi data, aniz byste to poznali.
Nebo teda zurnalovat i data, coz je vykonove nekde jinde. Cetl jsem ze
se pripravuje ordered mod pro XFS, ale podle vseho jeste neni.

: XFS podle nekterych trpi ztratovosti dat, podle nekterych nikoli, takze by
: me zajimaly objektivni nazory ze sveta serveru

	Jak pisu vyse. Zatim se mi nestalo ze bych na XFS prisel o data
nejak chybou filesystemu, ale v pripade padu stroje muzete mit (podle
zurnalu) zvetseny soubor, ale ne data v nem. Prakticky overeno na
XFS i JFS.

: JFS spousta lidi oznacuje za pomale.
: 
	Podle mych mereni (ale na neprilis paralelni zatezi)
byl JFS nejrychlejsi filesystem na prenos vetsich dat (tehdy jsem
meril ext3, XFS, JFS a ReiserFS).

	Na ftp.linux.cz bezi poslednich nekolik mesicu JFS
(spis abych to vyzkousel, protoze jsem s JFS nemel zatim prakticke zkusenosti,
nez ze by pro to byl nejaky extra vykonovy duvod). Jedina podivnost co jsem
zaznamenal (ale treba je to vlastnost :-) je, ze u JFS se vytvari zurnal
velikosti nejakeho pevneho promile z celkove velikosti disku, takze na
sedmiterabajtovem FS i pouhe projiti zurnalu po padu systemu trva peknych
par minut, protoze zurnal je obrovsky.

	Na web server to asi nevyuzijete, ale XFS a JFS maji DMAPI
(moznost vkladat nebo rusit data "uprostred" souboru s tim, ze zbytek
dat se "odsune" na vyssi offsety nebo naopak "prisune" na nizsi).

	Na XFS bylo zajimave jak spolupracuje se SW RAIDem - mkfs.xfs
si umi zjistit velikost stripu RAIDu i uroven prokladani a nejak pak
optimalizovat svoje operace podle tohoto.

: Cele pole chceme stavet na debianu, zvazovali jsme i variantu solaris -
: ZFS/UFS - muze nekdo posoudit, co je lepsi/horsi - nektera z linuxovych
: variant nebo solaris + ZFS ci UFS?

	UFS urcite ne. ZFS jsem v praxi nezkousel, ale podle diskusi
je tam problem s pametovymi naroky (uzivatele obcas hlasi ze system nad
ZFS zatuhava a je jim doporuceno pridat pamet - asi nejake low-memory
deadlocky).

: Pole bude sice samozrejme na zalohovanem napajeni atd., ale i tak muze dojit
: k vytuhnuti, nutnosti fyzickeho restartu, vypadku proudu atd. a samozrejme
: je naprosto prioritni, aby se neposkodila zadna data a nemuselo se treba
: restaurovat cele pole nekolik hodin.

	Pokud na to mate penize (jakoze s 15kRPM disky asi ano :-),
pouvazoval bych jeste o oddelenem zarizeni pro zurnal (nejaka pamet RAM
zalohovana baterkou), a nasadil bych ext3 (nebo podle velikosti te
pameti mozna i XFS nebo JFS se zurnalovanim dat. Divam se ze treba
tohle by mohlo byt zajimave - kapacita 4 GB je uz docela dost:

http://techreport.com/articles.x/9312/1

	Jo, jeste: pouzijte SW RAID, predejdete mimo jine takovym
tem problemum "odchazi mi radic, muzu ty disky nacist i nekde jinde?".

: Diky za tipy a preji pekny prichazejici vikend[image: Veselý obličej

	vmsplice(2) se mi postaralo o pekny zaver vikendu,
jen co je pravda :-/

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
>>  If you find yourself arguing with Alan Cox, you’re _probably_ wrong.  <<
>>     --James Morris in "How and Why You Should Become a Kernel Hacker"  <<