Vlákno názorů k článku FreeBSD řady 5 od pc - Jak je to s UFS2? Co nového přináší,...
-
pc (neregistrovaný)
No, právě jsem čekal něco trochu konkrétnějšího než "a vůbec". Třeba ty větší disky. Jak velké? UFS2 má pořád omezení že bitmapa použitých bloků pro cylindrovou grupu musí být v jediném bloku. To docela omezuje velikost cylindrové grupy. Jak velký filesystém si pak můžete dovolit, aniž by se první grupa zaplnila seznamem všech ostatních grup? Rád bych viděl nějakou dokumentaci jak struktura UFS2 vypadá. O FFS a Ext2 je toho dost, o UFS2 jsem nic nenašel. Taky by mě zajímalo, jak je řešená zpětná kompatibilita. Když má staré FFS superblok 8kB za začátkem zařízení a UFS2 64kB, může se stát že tam budou superbloky oba, jak se pozná o který formát jde?
Celkově mě FFS přijde jako dost primitivní filesystém a když už se vývojáři FreeBSD rozhodli zavést něco nekompatibilního, tak toho měli IMHO využít k radikálnějším změnám než jen umožnění větších adres na disku a podpory pro ACL. -
pc (neregistrovaný)
Podle dostupné dokumentace (http://www.mckusick.com/softdep/index.html) se mi zdá, že ani jedna s těchto vlastností není vázána na UFS2 a nevyžaduje změnu formátu filesystému (neb snapshoty jsou uloženy v obyčejných souborech).
Mimochodem, taky vám připadá, že fsck na pozadí je pěkná prasárna? -
pc (neregistrovaný)
Asi nejenom inodu, ale i dalsich potencialne poztracenych polozek, jako jsou bloky.
Takze v tom mountlem fs se provadeji nejake operace na zaklade toho jak vypada ten snapshot, procez je nutne predpokladat nejakou korelaci mezi nimi. Ale to je problem, protoze mezi tim je ten fs mountovany read-write. Autori zjevne veri, ze tuto korelaci znaji, protoze maji pod kontrolou implementaci FFS v jadre. (A veri, ze se vubec da nejaka korelace najit, coz nejakym zpusobem omezuje tu implementaci fs, aby k poruseni te korelace nedoslo.)
Nu, a to mi prave prijde jako prasarna. Tradicni fsck pokud vim nepotrebuje znat nic jineho nez format dat na disku a implementace mu muze byt ukradena.
Navic mi vubec neni jasne jak se da nejaka smysluplna korelace (mezi snapshotem a aktualnim stavem rw-mountleho filesystemu) bezpecne zajistit.
Uvazujme nasledujici pripad. Byl smazan soubor a adresar ve kterem byl obsazen. tedy jadro smazalo polozku v nadrazenem adresari a chtelo oznacit inodu adresare i souboru jako smazanou, kdyz tu system spadl. Po restartu se vytvori snapshot a na nem se pusti fsck. Projde adresare a zjisti ze na tyto dve inody nevede zadny odkaz, tedy jsou ztracene a mely by se smazat.
Mezitim nekdo otevre ten smazany adresar, najde ten smazany soubor (ktery prozatim vypada jako nesmazany) a smaze ho. Pak vytvori jiny soubor v nejakem nesmazanem adresari. V tomto okamziku se muze stat, ze jadro pouzije pro tento novy soubor tu smazanou inodu. A mame problem, protoze ted fsck tu inodu prohlasi za ztracenou a vesele smaze, cimz zpusobi jednak ztratu dat (smazal se soubor, ktery se smazat nemel), a dale nekonzistenci filesystemu - kdesi je polozka v adreari ukazujici na neexistujici soubor.
Pokud se divite, jak je mozne otevrit ten smazany adresar a neco v nem delat, tak si prectete manualove stranky fhopen(2) a fchdir(2) nebo si zkuste predstavit ze na tom stroji bezi NFS server.
Tolik k te bezpecne operaci. Mozna to maji ve FreeBSD osetreno, ale tim ze je nutno sledovat takoveto okrajove pripady se vse komplikuje, prestava to byt genialni a sklouzava to do prasaren.
Navic si moc nedovedu predstavit jak by to vlastne melo byt osetreno. -
neologism (neregistrovaný)
jojo, bloky taky
to co popisujete prave resi softupdates. ty totiz "seradi" operace tak aby jejich vykonani bylo bezpecne, tj. at uz se bude ve vami popisovanem pripade dyt cokoliv nikdy nedojde k nebezpecnemu serazeni operaci (ie. 1:read 2:read 2:write 1:write, kde cislo je proces apod.) nevim co se stane ale je nutne si uvedomit ze ten fs je jeden a co se pak bude provadet nad nim maji v operaci softupdates ktere prave tomuto zabrani...
takhle to chapu ja -
Mikulas Patocka (neregistrovaný)
Bezpecne to je (pokud v tom nejsou bugy). fsck na pozadi na freebsd nedokaze odstranit vsecky chyby (napr. zpusobene vadnym hardware), dokaze odstranit jen ty, ktere vznikly po padu systemu --- t.j. ztracene bloky a inody.
Idea je takova, ze pokud je nejaka inoda ztracena na snapshotu, bude ztracena i na skutecnem filesystemu, takze se muze odstranit. Odstrani se tak, ze fsck zavola funkci kernelu pro odstraneni inody, nehrabe na zarizeni rovnou, aby se spravne vyresila synchronizace s buffery.
Na Linuxu je take mozno pustit fsck na namountovanem filesystemu, ale tam to skutecne bezpecne neni, a nema se to delat, pokud o ten filesystem nechcete prijit. -
pc (neregistrovaný)
> Idea je takova, ze pokud je nejaka inoda ztracena na
> snapshotu, bude ztracena i na skutecnem filesystemu,
> takze se muze odstranit.
No to prave nemusi byt pravda, ke ztracenym inodam je totiz porad mozno pristupovat pres filehandly, pokud na tom stroji bezi NFS server ci se pouzije volani fhopen(2). A inody ke kterym je mozno (jakkoli) pristupovat neni radno odstranovat. -
Mikuláš Patočka (neregistrovaný)
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). Pokud se ji někdo bude snažit otevřít po fsck, tak otevření vrátí chybu. Pokud se mezitím na daném místě vytvořil jiný soubor, měla by jeho otevření zabránit jiná verze (na Linux tomu zabrání, předpokládám, že FreeBSD to má taky).
-
Mikulas Patocka (neregistrovaný)
ATA ma prikaz na flushnuti cache, FreeBSD ho umi pouzivat, o nem snad disky nelzou.
Linux tento prikaz neumi pouzivat (resp. pouzije ho pouze pri shutdownu), takze pokud pod Linuxem povolite cache pro zapis na disku, tak jsou data pri pouziti journaloveho filesystemu v nebezpeci (u nejournaloveho je to jedno, ale treba neni zaruceno, ze po fsync bude soubor ulozen).
ČLÁNKY DO MAILU