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 -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
