gjournal

[Miroslav Lachman]

Radim Kolar wrote:

> Testoval jsem gjournal znova a vypada to ze aby to ve zdravi prezilo:
> dd if=/dev/zero of=file na gjournal disku
> tak musi byt journal veliky jako operacni pamet. doporucovana velikost
> 2/3 nestaci. Je tedy potreba s journalem nesetrit a myslet na to ze v
> serveru muzeme casem pridat pamet.

Kde jsi dosel k tomu, ze by velikost journalu mela byt 2/3 velikosti 
RAM? Ja tomu zas az tak moc nerozumim, ale tohle vidim prvne a nikdy 
jsem necetl nic o spojitosti s RAM. Vzdy se uvadelo, ze velikost 
journalu musi byt takova (a me to zni logicky) aby se do journalu veslo 
tolik dat, kolik je disk schopen pojmout za dobu switch_time.
Defaultni switch_time je 10 sekund a pokud budu uvazovat, ze na 1TB 
Samsung mam na zacatku zapis okolo 115MB/s, tak by melo stacit 10*115 = 
1150MB. Tedy 2GB jsou dostatecna rezerva.

Pokud tedy mas nejaky link, kde se vysvetluje navaznost na velikost RAM, 
tak bych ho uvital.

> Pouziti gjournalu na notebooku snizi vydrz na baterky a stejne ztrati
> posledni ulozene soubory. soubor po Save + reset zmizi, coz delaji
> soft updates taky, takze jedina vyhoda gjournalu je ze se nemusi delat
> fsck coz je u ntb vyhoda. Jsou obvykle pomalejsi zapisy pokud
> nezapisuje hodne uzivatelu soucasne.

Aby nezmizel, asi by musela byt vypnuta diskova cache, ne? Jinak to 
zmizeni poslednich zapsanych souboru me ani neprekvapuje, pro me jde 
hlavne o konzistenci na filesystemu a nepotrebnost fsck.

> Rozhodne bych gjournal masove na serverech nenasazoval. Mne tedy
> server padne zhruba 1-2x rocne kdyz nema UPS. Spis bych sel do ZFS.

Mam ho na par serverech nasazeny asi rok a pul a problemy s nim nemam, 
ale je pravda, ze pro urcity workload to zpomaluje zapisy velmi citelne. 
Na druhou stranu cteni by tim nemelo byt nijak ovlivneno (podle 
puvodnich testu PJD to dokonce nekdy funguje rychleji).

Nejradsi bych taky nasazoval ZFS, ale ani to jeste neni vsehospasitelne 
a stale je s nim spousta problemu v urcitych situacich (i kdyz mi na 
dvou strojich funguje k me spokojenosti)
Zaroven je tu par veci nedoresenych a ani je nikdo neresi. Jako treba 
to, ze spare disky jsou v ZFS na FreeBSD jen na okrasu. O jejich 
aktivaci se na Solarisu stara jakysi daemon, ktery na FreeBSD vubec 
neni. Tudiz clovek si do RAIDu prida nejaky ten spare a doufa, ze az 
nejaky disk odejde, bude nahrazen automaticky sparem. Jenze to se 
nestane. (nebo aspon v dobe, kdy jsem to testoval, se to nestalo a podle 
informaci, co jsem o tom cetl, se to ani nema jak stat)

A aby toho nebylo malo, tak pro databaze, jako treba MySQL, to ZFS 
nedoporucuje ani sam Sun, protoze moc dobre vedi, ze je na nem MySQL 
vyrazne pomalejsi, nez na UFS (benchmark byl na blogu nekoho ze Sunu).

Mirek