Vlákno názorů k článku FreeBSD 5.3-RELEASE od maniac - podpora TCP STACKU? to je jaka novinka? :) a...
-
Článek je starý, nové názory již nelze přidávat.
-
neologism (neregistrovaný)
softupdates dela to ze preskupi zapisy metadat tak aby se na disku vzdy nachazela v konzistentim stavu. ve vysledku to ma ten efekt ze se nemuze stat (pokud disky nelzou, coz ata delaji) ze se system po crashi vyskytne v nedefinovanem stavu... ie. ze to po "tvrdem restartu" nabehne - mne to pripada ze to dela to same (sice jinak ale v dusledku to same) jako journalovani - co jsem nepochopil Oooo velky bojovniku?
-
remet (neregistrovaný)
No nevim ze by softupdates byl journal, ale kazdopadne, jeste se mi nestalo, ze by BSD se softupdates mel jakykoli problem ikdyz sem mu daval zabrat tvrdym vypinanim elektriky (pravidelne 1x za hodinu)... zato ani zdaleka takhle netrapeny linux (nepamatuju si distribuci) 2.6.x s reiserfs jsem videl po jedinem restartu tak nakopany ze 24 hodin trvalo samotne zprovozneni.
Mimochodem, asi jste pochopili, ze pracuji s BSD radeji, co me ale hodne uchvatilo na onom Linuxu, ze neni schopen spustit reiserfsck na namountovane partition, takze aby se dal opravit root, musi se nabootovat z CD. Nepochopitelne. -
Jarda Klaus (neregistrovaný)
Nepochybuji o tom, ze neologism i autor clanku vi, co je softupdates.
Problem je ale v tom, ze rada uzivatelu/administratoru zna pouze zurnalovaci FS jako jedinou moznou cestu k zajisteni konzistence FS.
Onen zjednodusujici popis je tedy ucelovy.
Vas popis je sice trochu presnejsi, za to ale, dle meho nazoru, pro drtivou vetsinou ctenaru nejasny. -
pc (neregistrovaný)
ad softupdates: snazi se to delat to same, ale je to jen nedokonala imitace, neb po tvrdem rebootu porad musi byt proveden fsck. (Pokud tedy nechcete pouzivat prasarny jako background fsck.) Cili to neni "takove lepsi zurnalovani", ale "takove horsi zurnalovani".
Tusim ze softupdates by mohly mit tu vyhodu ze se nemusi data zapisovat dvakrat (do zurnalu a pak na konecne umisteni). Ovsem vetsina zurnalovacich fs uz umoznuje hodit zurnal na jiny disk, takze ta vyhoda IMHO nebude tak velka (chtelo by to zmerit).
Co si zaslouzi oznaceni "lepsi zurnalovani" je LFS ze Sprite. To ma cely filesystem jako jeden velky zurnal, takze tato rezie take odpada a navic se pri zapisu nemusi prakticky nikdy seekovat. Zda se ze na podobnem principu funguje novy filesystem ZFS od Sunu. Je to opravdu vyrazne rychlejsi nez FFS (i v tom nejrychlejsim modu kdy se konzistence dat vubec neresi) i nez ext3. Mereni (pravda primitivni) muzu poskytnout. -
neologism (neregistrovaný)
pokud je LFS logovaci FS pak existuje vyzkumny paper popisujici journaling vs lfs vs softupdates a z nej jednoznacne vyplyva ze softupdates je lepsi nez dalsi dve alternativy, tento paper jde vygooglit a tusim nekde v fbsd softupdates je na to snad i nekde odkaz...
a ja verim vic vyzkumnikum z universit nez "hackerum z buhviodkud"
a to ze se musi delat fsck resi bgfsck, coz neni prasarna ale dobra vec (uz se to v diskusi na root.cz resilo)
tedy - softupdates dela to same co journaling ale dela to rychleji... ie. je lepsi;) -
pc (neregistrovaný)
Ano, takove papiry existuji. Autori v nich srovnavaji vykon soft updates se _svou vlastni_ implementaci zurnalovani, ktera pokud vim byla udelana pouze pro ucery toho papiru, coz mi pripada ponekud nesrovnatelne s zurnalovacimi filesystemy ktere jsou v produkcnim nasazeni.
Ale i kdyby: korektnost by mela byt na prvnim miste a dulezitejsi nez rychlost - k tomu je pekna hlaska "Sure it corrupts my files, but look how it is fast!" (Garfinkel & spol.). bgfsck podle me korektni neni (uz se to tu resilo, jak si spravne vzpominate a nechci se opakovat.) Tolik k "rychleji je lepsi".
Co se tyce LFS, ti "vyzkumnici z univerzit" se jaksi nemohou shodnout: viz http://www.eecs.harvard.edu/~margo/usenix.195/ouster_critique2.html
Co se tyce "hackeru buhviodkud", pokud chcete vysledky od nekoho verohodnejsiho, muzu doporucit treba http://mail-index.netbsd.org/tech-perform/2003/03/30/0000.html
(Frank van der Linden delal port softdeps pro NetBSD.) Vychazi mu ze pro metadatove operace je LFS vyrazne rychlejsi nez FFS. (A pritom udrzuje co do vysledku stejnou konzistenci dat jako zurnalovaci filesystemy - boot je okamzity, zadny fsck, ani bgfsck.) Pri zapisu dat je o neco pomalejsi, pokud ale mate takovou ulohu, tak vam asi nebudou vadit zurnalovaci filesystemy, protoze zurnalovani zpomaluje jen metadatove operace. -
neologism (neregistrovaný)
naprosto souhlasim - ono urcite zalezi na typu zateze atd. (afaik ani v netbsd se nepouziva lfs na nic jineho nez tusim /var/log nebo tak neco ne?).
lide maji proste na ruzne veci ruzne nazory - tak uz to chodi ;)
to s tim bgfsck jsem resil s tebou? pokud ano - proc jsi nevzal tu argumentaci kterou napsal $nekdo_jiny_nez_ja do te diskuse? -
pc (neregistrovaný)
Jo, se mnou. Kdo je to $nekdo_jiny_nez_ja a do jake diskuse jsem tu argumentaci mel vzit? Jestli to mam byt ja a jestli se mysli ta diskuse na webu na Rootu (http://www.root.cz/forum/diskuse.php4?clanek=2366&vlakno=0&stav=0&vse=Zobrazit+v%B9e), tak jsem to tam nekopiroval proto, ze 1) ta diskuse byla hrozne dlouha a zdejsi system prispevku na to nejak neni staveny, a 2) nepripadalo mi ze bych pouzival nejake nove argumenty, jen jsem rozvedl to, cemu jsi predtim nerozumel. Klidne vezmi to co ti pripadalo podstatne a prekopiruj to tam.
V NetBSD se defaultne LFS nepouziva vubec, protoze ta implementace ma nejake zasadni chyby (tuzim ze nelze korektne resit preplneni disku). Coz ovsem neni chyba toho principu LFS jako takoveho.
BTW nedavno se mi povedlo preplnit LFS partition a nic hrozneho se nestalo, takze bych se toho tolik nebal. -
pc (neregistrovaný)
To "vysvetleni" podle meho vubec neukazalo proc je ten muj dlouhy protipriklad s fhopen a smazanym adresarem nespravny. Pocitadlo otevreni to podle me nezachrani, protoze neni problem ty inody se kterymi jsem takto manipuloval vcas zavrit, takze pocitadlo bude 0 a k uvolneni dojde.
cituji:
> Inoda je fyzicky odstraněna, pokud její počítadlo
> hardlinků klesne na 0 a pokud její počítadlo
> otevření (drženo v paměti) klesne na 0. Takže
> pokud tu inodu někdo měl otevřenou před fsck, fsck
> ji neodstraní (pouze způsobí, že bude smazána, až
> bude zavřena).
A co kdyz ji stihnul zavrit? Pak ji fsck odstrani, a pokud jsem mezitim vytvoril na ni hardlink nekde jinde, tak je to nekorektni.
Nemluve o tom co se stane kdyz ta inoda mela naalokovane datove bloky, ja ji otevru a ten soubor zkratim, cimz jadro ty bloky oznaci jako uvolnene a nic mu nebude branit v tom aby je pridelil jinemu souboru. Mezitim i fsck dospeje k zaveru ze ta inoda byla smazana, tudiz ty bloky uvolni znovu a ten jiny soubor ma smulu - jeho bloky byly nekorektne uvolneny. -
JaRo (neregistrovaný)
DevFS - Pouzival jsem (a jeste nekde pouzivam) v Linuxu, funguje bez problemu. Us je ale v Linuxu rady 2.6 delsi dobu oznacen jako deprecated (zastarale, casem bude odstraneno). Nahrada napr. udev ktery bezi v user mode, ne v rezimu jadra.
Celkem pekne, Linux to opousti a BSD to teprv stabilizuje. No uvidime jak se budou vyvijet dal v budoucnu, zda u devfs BSD zustane, jak dlouho to ponecha Linux (ja jsem mel s DevFS dobre zkusenosti), ... -
DanGer (neregistrovaný)
sorry za ten STACK, chybicka se vloudila ;-)
ohladom toho softupdates, tu je daky paper, ja som to cele necital, ale koho to naozaj trapi a zobral prilis vazne to podrypnutie ohladom journalingu a softupdates, tak nech si to precita a da nam presne vediet :)
<a target="_blank" href="http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer_html/index.html">http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer_html/index.html</a>
