Ext 4 je označeno za stabilní teprve krátce a nyní se začaly objevovat problémy. Kromě jiného přináší Ext 4 také zpožděnou alokaci. To znamená, že když vytvoříme soubor a zapisujeme do něj data, tak ty se drží stále v paměti a na disk se nic nezapisuje. Některé desktopové aplikace (Firefox) nebo rovnou celá desktopová prostředí (KDE a Gnome) pracují se svými konfiguračními soubory tak, že je smažou a znovu vytvoří. Když se tak stane a systém chvilku po tom zhavaruje, nebudou tyto soubory zapsány na disk a zmíněné programy bez nich třeba již nenajedou. Problém se netýká jen Ext 4, ale také XFS nebo Btrfs.
Ext4 pomohlo odhalit „špatně“ napsané aplikace
12. 3. 2009
79
nových názorů
-
yossarian (neregistrovaný)ano? nepamatuju se, ze by se mi nekdy v xpckach nebo vistach sama "vysrala". to ze mate leve pracky neni problem OS.
-
Jakub D. (neregistrovaný)Jasne, na win registry se vzdycky snese spousta kritiky, ony samozrejme nejsou dokonale. Ale myslenka ukladat nastaveni systemu nebo aplikaci do databaze neni spatna. Jen bych pouzil neco pruhlednejsiho a otestovaneho. Treba SQLite, tuhle db, tusim, nejaky open-source projektu jiz pouziva (prosim, doplnte me). A pak uz je jen krucek k centralizaci do jedne db spolecne pro cely system. Jen bych pak pouzil MySQL nebo PostgreSQL nebo tak nejak. Proste neco znameho, overeneho a otevreneho. Ne podivne win registry. Jo a ta dababaze by nakonec mohla byt i objektova nebo relacne-objektova, konecne i ruzne ty ruzne settingy se dnes drzi objektoveho schematu - myslim ruzne cleneni do podskupin a zavislosti mezi nimi.
-
Jakub D. (neregistrovaný)Jasne, ja netvrdim opak. S SQLite sam zkusenosti nemam, uvedl jsem jej jen jako priklad. Proste si myslim, ze databaze maji aplikacim v ohledu konfigurace co nabidnout. Diskutovat o tom, ktera je nejlepsi pro dany ucel (objektova x relacni x objektove-relacni x xml, MySQL x PostreSQL x ...), muzeme cely den :-))
-
Zrovna na tu historii jsou lepší soubory – dají se verzovat třeba pomocí Mercurialu (používám na /etc). A když se pak něco „vysere“ dá se snadno vrátit zpátky – pokud tedy člověk ve vhodných okamžicích (či pravidelně) „commituje“ :-) Verzování v databázi je vždycky trochu ‚opruz‘ – ale zase to má jiné výhody. -
Jakub D. (neregistrovaný)Z vaseho prispevku citim sarkasmus. Ale verte, ze zhruba to, co popisujete, velke firmy pro sve aplikace vyzaduji. Tedy az na ta casova pasma a zrcadleni "okolo cele zemekoule". Uplne staci par zrcadel do kazdeho aktivniho regionu - EMEA, LATAM, NORAM, JAPAC.
Treba americka pobocka Deutsche Bank po 11. zari 2001 prisla o sedm zamestnancu a vsechna originalni data. Bez funkcnich zrcadel by business uz asi nerozjeli. Podobne si myslim, ze vas prispevek by neocenily spolecnosti sidlici v oblastech suzovanych hurikany, zemetresenimi a dalsimi katastrofami (Kalifornie, Florida, Japonsko, ...). -
Bilbo (neregistrovaný)Ukladat systemove nastaveni do databaze je padle na hlavu. Pokud se tam ulozi neco natolik spatneho, ze uz system kvuli tomu nenabootuje, tak oprava byva dosti obtizna (z live CD je jednoduche poeditovat textove konfiguraky, u binarni databaze by tam musel byt nejaky specialni nastroj a pokud se treba u te DB nejak nabori index tak, ze se to uz nespravi, tak je clovek v loji .... z binarniho blobu se uz nezachrani obvykle nic, z textove konfigurace clovek vystipne poskozenou cast a muze ji zkusit dopsat odjinud (treba z defaultni konfigurace))
Navic implementace ve windows, kdy registry nejdou rozumne zalohovat (ani admin nema sanci si je nekam rozumne zkopirovat) je obzvlaste nestastna (taky spousta aplikaci do registru uklada veci ktere by tam asi patrit nemely (nacachovane thumbnaily), byt to je spis problem tech aplikaci nez systemu, kazdopadne vysledkem je dosti bordel) -
Jakub D. (neregistrovaný)Hele, ja tady neobhajuji zadne dogma. Kazdy nastroj ma trosku jine vyuziti a ja netvrdim, ze nastaveni ulozene v db je samospasne. Ok, se systemovymi zalezitostmi souhlasim, tam bychom se pripravili o moznost rucni opravy, tedy bez specializovanych nastroju.
Ale spousta desktopovych aplikaci potrebuje proste uzivateslka data proste nekam ulozit a pak je v poradku nacist. Tak proc to vyvojarum nezjednodusit - typovost ulozenych hodnot, podpora objektove-relacniho modelu, transakce, zurnal (viz. clanek), zalohovani, system opravneni atd, to vse muze vyvojarum pomoci. Protoze tuhle funkcionalitu si stejne vyvojari musi nejak napsat sami. Kdyz uz pouzivame Qt nebo GTK pro GUI, tak proc nepouzit nejakou knihovnu pro jednotne reseni konfigurace pomoci db? Staci jen nebat se porusit zazita dogmata, ze konfigurak *musi* byt textak, popr. xml. -
„Tak proc to vyvojarum nezjednodusit - typovost ulozenych hodnot, podpora objektove-relacniho modelu, transakce…“
A kdo jim to zesložiťuje? :-) Vždyť stačí mít nainstalovanou PostgreSQL (s „ident sameuser“) a každá aplikace ať si založí svoje schéma a do něj si nastavení ukládá. Klidně si do těch tabulek může ukládat třeba XML dokumenty :-) -
Jirka (neregistrovaný)Tak v prvni rade by bylo fajn, kdyby existoval jeden styl konfiguraku, treba nejake DTD v XML. A pak by nebyl problem, aby si kazdy mohl vybrat, jestli chce opravdu textaky v XML (nebo dokonce v necem jinem, co umozni stejne figle), nebo v registrech nebo treba vytetovane na zadech. Tohle by uz byl back-end za nejakym uzivatelsky (programatorsky) privetivym front-endem, ktery by nerozlisoval, jak jsou dane konfiguraky ve skutecnosti zapsany.
Jakmile by tohle existovalo, dalo by se premyslet, jak to implementovat lip a lip. Treba by se nakonec ukazalo, ze nejlepsi by bylo tahle data ukladat na zvlastni diskovy oddil, kde by fungoval zurnal, prava atd... prizpusobene potrebam konfiguraku. Nebo neco jineho (treba soubory v /etc :-)). Podstatne je, ze kazdy by si mohl vybrat, co prave jemu vyhovuje. Nekdo pozaduje rychlost, nekdo zase bezpecnost, nekdo zase aby si mohl konfiguraky cist jako detektivku. A vsechny konfiguraky by vypadaly stejne (a nebo taky ne - neni duvod, proc by cast konfiguraku nemohla byt ulozena jinak nez jina cast - kazdopadne by byly pristupne pomoci jednoho front-endu).
Zapisovani a cteni konfiguraku neni obvykle nejaka kriticka operace, takze to muze byt i pomalejsi, nez by pro dany pripad bylo mozne. -
Tohle je nesmysl – použití XML pro konfiguráky je dobré, resp. asi nejlepší, ale není možné vytvořit jedno DTD použitelné pro konfiguráky různých aplikací – leda že bys ten konfigurák degradoval na dvojice klíč hodnota zapsané pomocí XML. Případně bys mohl ono univerzální DTD navrhnout aby neumělo jen klíč=hodnota, ale i strom, obsahující tyto dvojice…
…bystří už možná vědí…
…ano, XML samo o sobě je takovým stromem, XML jako takové je formát a standard, který se dá dobře používat, není potřeba dělat univerzální DTD platné pro všechny aplikace – tohle je úplně zcestný přístup a nepochopení XML. Je také dobré se zamyslet nad sémantikou – pokud budu mít univerzální DTD (či schéma), mám tam prakticky dvojice klíč=hodnota, zabalené do ostrých závorek, tudíž jen tak nevím, co to je za data (obecně nevím, co znamená klíč "abc.wer.sfg", to ví jen ta aplikace, která ho používá) → proto můžeme pro konfiguráky používat jakékoli XML, stačí, když bude validní – sémantice nebudeme* rozumět tak jako tak, ale v případě, že nevnutíme aplikacím nějaké „jediné správné univerzální DTD pro ukládání konfiguráků“, jim dáme možnost naplno využívat výhody XML, protože každá aplikace si může napsat DTD podle vlastních potřeb (aby odpovídalo strukturám, které je potřeba ukládat).
*) z pohledu nějakého univerzálního nástroje nebo API -
Lael Ophir (neregistrovaný)Na editaci textu potřebujete textový editor, na editaci XML potřebujete XML editor, na editaci konfigurační DB zase asi editor konfigurační DB. Nevidím to jako zvláštní nevýhodu.
Binární strukturu lze samozřejmě také opravovat. Viz běžné DB, viz fsck. Možnost porušení binárních struktur existuje i na vlastním FS, ale není to důvod kvůli tomu FS zavrhovat. Navíc se podívejte na existující implementaci. Ve Windows k problémům s poškozením konfigurační DB prakticky vůbec nedochází (nebavíme se o hodnotách v té DB), a navíc je vždy udržována Last Known Good Configuration.
Registry samozřejmě lze zálohovat, umí to i backup vestavěný ve Windows. A které aplikace ukládají do registry thumbnails? -
JardaP (neregistrovaný)Uz se tesim, jak si v MC oteviram nejakou databazi namisto textaku. Doufam, ze tam do te doby dodelaji databazoveho klienta. :-)
BTW, myslenka registry mozna ma neco do sebe, ovsem ne MS prasecina, kde je vse rozptyleno po cele databazi zcela nahodne tak, ze clovek nikdy nedokaze dohledat vsechna nastaveni tykajici se konkretniho programu. Tez, kdyz nekdo prijde s necim, jako je registry, cekal bych, ze jiz od prvni verze k tomu bude opravny nastroj spustitelny z Widli a pro nejhorsi pripady, kdyz uz Widle nenajedou, tez bootovaci disk s opravnou utilitou a podporou FS obvyklych na dane verzi Widli. Na oboji se MS vydlabl s tim, ze se ma zalohovat registry. Uz vidim, jak kazdy honem zalohuje registry po kazdem updatu. Navic clovek nikdy nevi, kdy registry zacalo byt namrsene a jestli uz nezalouhuje nabouranou verzi. A prictete si spolehlivost 3.5" disket...
Jedine, co kdy MS zplodil, bula nepodporovana utilita z doby Win NT 4.0 a od te doby nic. Web se sice hemzi vselijakymi registry cleanery, ale cert jim ver, ze nenadelaji vice skody, nez uzitku.
Textaky maji sice sve slabiny, ale jejich obrowskou silou je opravitelnost ci nahraditelnost i za obzvlaste neprizniveho pocasi, coz se o registry rici neda. Cili ne, dekuji. Spokojim se se zastaralymi textaky, o ktere by si LO ani kolo neoprel. -
Více či méně náhodný kole (neregistrovaný)Nejsem člověk, který by se měl tendenci zastávat MS, nicméně, od dob Windows 98 si systém automaticky dělá zálohu registrů po úspěšném nabootování (to vím zcela jistě, protože jsem si několikrát z ní zachraňoval systém, když po nějakém ne tak docela povedeném experimentu s low-level device driverem nenaběhl).
Jistě, můžeme oprávněně namítat, že Windows 95 a spol. podobnou vlastnost neměly (byť mám neurčitý pocit, že ve Win95B už jakýsi náznak existoval) a že toto řeší následek a nikoli příčinu, ale taky bychom se neměli uchylovat k tvrzením, která byla aktuální před deseti lety, to je jen pozvánka pro fanatické MS trOLy. -
Lael Ophir (neregistrovaný)To jsou zase perly. Konfigurace není v Registry náhodně rozptýlená, ale umístěná do cesty, kde jí autor aplikace zamýšlel uložit. A že jedna věc může mít konfiguraci na více místech? Když máte řekněme ekonomický systém na unixu, také má konfiguraci DB a aplikačního serveru na různých místech. Podobně u OOo těžko rozlišit konfiguraci Writeru od zbytku OOo, protože je řada komponent sdílených v rámci celého balíku.
Windows mají na instalačním médiu automatický repair, což je užitečná feature. Záloha Registry se pořizuje automaticky, a vždy máte Last Known Good Configuration, o čemž se vám s konfiguráky může jen zdát. Utilita pro registry cleaning z NT4 se podle všeho starala o HODNOTY zapsané v Registry, ne o vlastní Registry jako úložiště hodnot; a stejné je to s těmi pochybnými "čističi registry" pro lamy. Je to asi podobné, jako byste měl na Linuxu utilitu, která proskenuje /etc a ~/.* na nesmysly (třeba odporující si nastavení, deamony startující z neplatných cest, a duplitity sekcí a klíčů v konfigurácích), a pak tvrdil, že taková aplikace je na Linuxu hrozně potřeba. -
Tak to jste štastný člověk, že se vám to nikdy nestalo. Hm, a dovolím se zeptat, používáte taky krom Poznámkového bloku něco jiného? Děkuji za odpověď. Každopádně jste jeden z mizivého počtu. Mě se tedy problémy s registry nyní úspěšně vyhýbají. Asi to bude tím, že je již nepoužívám. Ubuntu (a mnoho dalších kvalitních distribucí linuxu) je mnohem lepší, bez urážky. Zbavilo mě závislosti na 3D hrách a konečně, díky bohu za ty dary, nezažívám všudypřítomné restarty. Ještě dodám, že na MS Windows jsem měl všechny updaty, sw jsem se snažil aktualizovat jak to šlo (opravdu je smutné, že Windows ještě nemá repozitáře a mnohem jednodušší správu ověřeného sw od poskytovatele OS). Já tedy s registry skoro problémy neměl (pokud jsem si nehrál s jejich obsahem), ale hodně uživatelů, co o PC moc nevědí a pro které by MS Windows mělo být tedy vhodné, mi stále naříká, jak jim nefunguje to či ono. Já abych pak k nim jezdil a opravoval poškozené registry? Hm, děkuji. Dnes už jim říkám, ať si zaplatí "opraváře", já na tohle nervy opravdu nemám. Ale znám i lidi, co mají Vistu a žádný problém prý nemají (to říkají po tom, co jsem jim těžce zprovozňoval wifi - všeobecný problém na Vistě). -
yossarian (neregistrovaný)Ano, pouzivam, ted jsem mj. pripojeny pres wifi na vistach, ktera mi na nb bezi spolehlive bez reinstalace rok a pul. uptime mam ted 2 dny, vybil se mi ve skole.
To, ze jste byl zavisly na 3d hrach nebyla chyba systemu, ale Vasi slabe vule, tak to sem netahejte.
A uzivatele, kterym se ve vistach neco vysere? Uz se mi stalo, ze mi prisel od kamarada pres IM virus.. Pisu mu, ze tam ma viraka, at nepousti sracky z linku, ke kterym mu nikdo nic nenapise, nebo at nainstaluje antivir. "Ja tam antivir mel, ale vypnul jsem ho, protoze rval, a byl jsem zvedavy co mi to ten znamy posila". Pak to svadejte na OS, kdyby takovy clovek mel linux, a program po nem chtel prava, tak 'su -c' to jisti ;]
mnohem jednodušší správu ověřeného sw - fakt? vite o cem mluvite? treba.. digitalni podpisy potrebne pro import do GAC, ..? -
To, že vám osobně funguje wifi rozhodně neznamená, že takto dobře jede všem. Mě taky na XPčkách funguvala skoro vždy, pokud jsem používal sw dodaný výrobcem, nativně velmi blbě, je ale pravda, že Visty nemám, jen u kamaráda. Děkuji nechci. Já bych o tom nepsal, kdybych to nemusel pořád u známých řešit. Zvláštní, že od té doby, co je pořádný ovladač na linuxu, tak už nemám žádné problémy a systém natvivně zvládne každou wifi, co vidí.
O těch 3D hrách byla trochu nadsázka, je vaše věc, že mě berete jako závisláka bez vůle. Ok, je to vaše věc. Když o mě nic nevíte, hned nesuďte, nemám to rád.
Co se týče toho viru, tak jsem tu vaší hlášku opravdu nepochopil, můžete mi to přeformulovat do češtiny? Link místo odkazu ještě skousnu, ale z vaší zprávy nevyplývá, zda se vám to stalo na Windows nebo na Linuxu (ano, opravdu jsme na portálu zabývajícím se linuxem, zajímavé, že). Ale ok, vydedukoval jsem, že mluvíte o Windows. Jasně, že mohu použít sudo (konkrétně v Ubuntu), ale jakmile ho používám, vím, že dávám programu neomezené možnosti. Mě to tedy třískne do očí. Pokud je uživatel tak naivní, že su či sudo dává všude, tak :-D pápálálá.
K té správě - repozitáře těch "lepších" distribucí jsou kontrolovány, nemluvím o těch neoficiálních. Teď tu nechci nic plést, ale mám dojem, že základní repozitáře podepsány jsou ;), mám tak problém třeba u Wine, když nepřidám podpis, to pak správce řve při každé instalaci wine atd.
Abych vám jen vše nevyčítal, opravdu nevím, co je GAC, do příště prostuduji. Asi jsem lama ;). A já se za to nestydím. -
Lael Ophir (neregistrovaný)MadWifi také nic moc. Nefungovaly "pokročilé" věci typu ad-hoc mode a WPA-PSK, zamrznutí Linuxu při inicializaci driveru, při připojení k síti, do 20 minut po připojení k síti, dočasné zastavení stroje během inicializace driveru a připojování k WiFi atd. Přitom karty Atheros byly považovány za slušně podporované.
Malware už nepotřebuje oprávnění roota. I v kontextu běžného uživatele může malware běžet ve vaší session, odesílat spam, posílat HTTP či DNS požadavky, a stahovat si vlastní "aktualizace". -
Lael Ophir (neregistrovaný)5 minut upravuji příspěvek, aby neobsahoval zakázaná slova, a nebyl považovaný za spam. TO NENÍ NORMÁLNÍ K*RVA!!! ;)
http://www.youtube.com/watch?v=4fzR4n6o_UE -
Bohdan (neregistrovaný)Ale ne, ext4 pouze natahla "nebezpecnou" dobu pro data z cca 5s na 150 za cenu urciteho narustu vykonnosti. Tedy pokud budu ukladat do db-like storage, tak se s tim nic neporesi, protoze pri padu dojde ke ztrate transakci, tedy i ztraty novych dat (samozrejme pro tohle je pak dulezite, aby DB podporovala ACID, coz o win-registrech pochybuju). Hadat se o tom, zda prijit o posledni transakci nebo o data v tomto pripade je bezpredmetne
To co je opravdu problem je nasledujici:
cp file file1
rm file
<reset/crash>
Obavam se, ze v tomhle pripade ext4 neni uplne to prave orechove -
- Výhoda DB by byla v transakcích – sice přijdeš o nová data, ale zůstanou ti aspoň ta stará (v případě, že ti to spadně ještě před commitem …nebo krátce po něm) – ale nepřijdeš o všechno.
- BTW: Jak se Java vyrovná s transakcemi u souborů.
-
Lael Ophir (neregistrovaný)Ve Window ukládáte informaci do Registry, takže není nutné kompletně konfiguraci mazat a znovu vytvářet. Navíc Registry má transakční mechanismus, takže pro každou konkrétní hodnotu najdete buď novou hodnotu, nebo tu starou (žurnálování Registry). Navíc Windows umožňují ACID transakce, takže můžete transakci začít, zapsat změny do několika různých DB, změnit hodnotu v Registry, založit soubor, přejmenovat soubor, a pak teprve celou tuto transakci potvrdit nebo odrolovat. Jde o využití 3-fázového commitu a transakčního koordinátoru. Skoro bych řekl, že unixům tohle bude ještě chvíli trvat.
-
Zd.Valek (neregistrovaný)FUUUJ, doufam, ze k tou nikdy nedojde na linuxu. Neznam nic lepsiho, nez konfiguracni soubory, akorat by se nemusely vsechny valet v ~, delaji tam neskutecny borde.. A ta vlastnost ext4 o ktere se pise je IMHO neprijatelna. Neco napisu, pak dam ulozit, sem v pohode, myslim si ze to mam ulozene a pak vypnou elektriku... a sem ... vite kde.
-
c3 (neregistrovaný)tak jeste jednou, pokud neco napisete (fwrite) date ulozit (fsync) tak o nic samozrejme neprijdete. pokud vsak jen neco napisete (fwrite) tak se pak nedivte ze se to neulozilo..
to je jako v textovem editoru: pisete do dokumentu a pak ho(textovy editor) bez ulozeni vypnete a divite se, ze se neco/nic neulozilo, kdyz to prece pred tim, v jine verzi editoru, ktera mela zapnuto automaticke ukladani po 5sec, vzdy fungovalo.. -
Yenya (neregistrovaný)Tady je trochu problem s tim, ze u mnoha typu souboru aplikacni programator nechce striktne "vynutit ulozeni". Pokud programator dela open("config.tmp"), write(), close(), rename("config.tmp", "config"), tak vicemene chce "budto starou nebo novou verzi dat, je mi to jedno" (POSIX nic takoveho negarantuje, nicmene v podstate vsechny filesystemy se takhle nejak chovaly (az po XFS/ext4/ZFS/vse co dela odlozenou alokaci).
Alternativa open("config.tmp"), write(), fsync(), close(), rename("config.tmp", "config") je zbytecne silna. Aplikaci obvykle nezajima aby na disku byla ta novejsi data - chce budto konzistentni stara, nebo konzistentni nova data (nejlepe aniz by aplikace musela cekat na nejakou diskovou operaci). Coz prostredky POSIXu bohuzel neni jak jadru rict - fsync() je prilis silne. Myslim ze pristup ext4 ve 2.6.30+ (vynutit alokaci a tedy i zapis dat pred metadaty pri close() a truncate()) je vicemene spravny.
-Yenya, http://www.fi.muni.cz/~kas/blog/ -
Michal Kára (neregistrovaný)Pokud to chapu dobre, tak jde o to, ze aplikace vytvori novy soubor, zapise do nej konfiguraci, a pak jej prejmenuje na misto stareho souboru. To je casto pouzivana technika na UNIXech, protoze semantika UNIXovych FS v tomto pripade zarucuje (nebo alespon doposud zarucovala), ze v pripade padu systemu v souboru bude BUD cela stara NEBO cela nova verze. Proste soubor bude konzistentni. Totez plati pro pad aplikace.
Pokud byste prepisovali primo stary soubor, mohlo by se stat, ze system/aplikace spadne v pulce zapisovani a v souboru bude polovina dat z nove verze a polovina ze stare => bude nekonzistentni a nejspis k nicemu.
Pokud pod ext4 toto nefunguje, tak to vidim jako jednoznacny bug FS. -
anonymníPresne takhle to funguje .... prepisuje se stary, i kdyby se mazal, tak je to jedno, ty data tam fyzicky na disku jsou a nulama se to nemaze. Jde o to, ze kdyz system padne v pulce zapisu 5MB konfiguraku, tak jsi v prdeli a existuje vysoka sance, ze te ceka kompletni reinstal systemu, coz je skoro smesne, ale je to tak ...
nejlip se to vyzkousi treba na vmwaru, kde priblizne v 50% kdyz se takhle linux natvrdo zabije, tak uz nikdy bez problemu nenajede (vetsinou treba Xka, serou se aplikace atd).
Windows takhle zabijim ve vmwaru 5x denne a doposud nikdy sebemensi problem ... ze by snad ten princip DB s zurnalem pro konfiguraci - registry, nebyl az tak spatny?:o) -
Michal Kára (neregistrovaný)??? vzdyt prave pisu, ze se stary neprepisuje, ale vytvori se novy a udela se rename.
Timhle se da pekne udelat transakce ("vsechno nebo nic") na urovni FS. A hodi se to nejen kvuli padum, ale pokud chcete menit soubor, ktery nejaka jina aplikace periodicky otevre-precte-zavre. Vytvorite novou verzi a pak udelate rename a mate zajisteno, ze aplikace precte bud starou, nebo novou verzi. Na Windows tohle nefunguje a obcas mi to docela chybelo. -
Lael Ophir (neregistrovaný)Tady je problém v té delayed allocation. Při vlastním zápisu se na disk nezapíše nic. Může dojít ke stavu, kdy vytvoříte soubor A, zapíšete do něj, smažete soubor B, dojde k havárii, ale soubor A po restartu neexistuje díky delayed alokaci. Linux je na podobné věci náchylný. Byl to tuším RFS, u kterého se stávalo, že thread A vytvořil soubor, dostal zpátky handle, thread B se snažil do souboru zapsat, a zápis selhal, protože soubor podle RFS ještě neexistoval. A pokud si vzpomínám, "opravovalo" se to úpravami aplikací (konkrétně MTA). Při návrhu se holt musí uvažovat :/
O kus vedle jsem popisoval, že Windows Registry má transakční mechanismus, takže každá hodnota v Registry bude obsahovat buď novou, nebo starou hodnotu. V případě Linuxu můžete přijít o celý konfigurák. -
jenze windows se argumentovat neda - oni totiz evidentne ty registry na disk zapisuji nekdy pri odhlaseni uzivatele nebo vypnuti systemu. Pokud se do nich neco zapise a natvrdo resetujes system, tak po dalsim bootu tam ty zapsane informace proste nejsou. Jinak si nedokazu vysvetlit to, ze kdyz neco nainstalujes a pak se ti resetne pc, tak ta aplikace se tvari jako ze neni nainstalovana. Nebo jsme na jednom serveru zmenili regionalni nastaveni, pak se ty wokna musely natvrdo resetovat (cely to zatuhlo nebo uz nevim proc), kazdpopadne po restartu tam bylo zase to stare nastaveni a clovek to mohl prenastavit znovu. -
anonymníA máte vyzkoušené, že se změny do Registry zapsaly? Je dost možné, že se nastavení změnilo jen v aplikaci, a do Registry se zapíše až v případě ukončení té aplikace.
Řeč byla ale primárně o tom, že u Ext4 dochází ještě častěji k tomu, že se konfigurace úplně ztratí. To se vám ve Windows opravdu nestane. Když zapíšete hodnotu do Registry, a dojde k přerušení napájení, tak tam po rebootu najdete buď starou hodnotu, nebo novou. Určitě se nestane, že by vám kvůli tomu odpadnul daný klíč (tj. node stromu) Registry. -
tukan (neregistrovaný)Presne tak, aplikace cekaji, ze se samo od sebe stane neco, co jim nikdo nezarucuje. Pokud to chteji, maji moznost si to explicitne vyzadat. Co jsem videl ty scenare, pri kterych to nastava, tak to bylo vzdy spatne naprogramovane. Nefungovalo to spravne ani dosud, jen to casove "okenko", kdy se to mohlo projevit, bylo mensi a tak to tolik nevadilo.
-
Sam (neregistrovaný)To je stary 'problem', ktory som prvykrat okusil uz na XFS.
Riesenie je jednoduche a imho jedine, /home, /etc a podobne adresare s vyssou frekvenciou zmien suborov ext2/ext3. Na datove adresare XFS/ext4 atd...
Mozete mat crash proof filesystem alebo rychly journal filesystem, oboje asi tazko. Iba tak hodit journal na nejaky SRAM. -
anonymníTam se nabízí otázka, proč nemít jeden FS, který se dá rozumně používat.
Na Linuxu i ve Windows je možné při otevírání souboru specifikovat write-through flag (O_FSYNC resp. FILE_FLAG_WRITE_THROUGH). Pak by neměla probíhat delayed allocation, a data by měla být zapsána na disk před návratem z příslušného volání. Otázka je, jestli to tak s Ext4 opravdu funguje. S ohledem na "kvality" Linuxu bych na to nesázel. -
c3 (neregistrovaný)no tak si to radsi prectete jeste jednou, toto neni problem EXT4 ale spatne napsanych aplikaci, to same se Vam muze stat na vsech modernich FS s asynchronnim zapisem, staci se jen s vypadkem trefit do spravneho okamziku. "problem" EXT4 je, ze to okno pro "trefeni se" je velmi velke takze je narozdil od jinych FS vetsi pravdepodobnost, ze se to podari...
-
anonymníSpravne slovo neni "asynchronni zapis", ale hlavne "odlozena alokace". A ano, ZFS se tohle tyka taky.
-Yenya, http://www.fi.muni.cz/~kas/blog/ -
Yenya (neregistrovaný)V pripade konfiguraku je reseni jednoduche - fsync(2). Dokonce tim ziskame lepsi stav nez predtim (uzivatel vzdy uvidi "novy" stav i po havarii, zatimco takhle nekdy videl az 5 vterin stary v pripade ext3). Problem je co s "malymi datovymi soubory" (typu cache browseru a podobne) - tam fsync(2) nechci delat, protoze me nezajima jestli uvidim stary nebo novy soubor, ale potrebuju jen garanci, ze kdyz uvidim nejaky, bude mit spravny obsah. Na coz je fsync() prilis silne.
-Yenya -
Lael Ophir (neregistrovaný)Bohužel fsync() v řadě případů provede flush veškerých souborů otevřených na daném FS, což může trvat velmi dlouho. Navíc race condition nezmizí. Pořád se může stát, že smáznete starý konfigurák, ale už nestačíte přejmenovat ten dočasný na nový. Konfiguráky byly původně navrženy pro servery, které běžely měsíce bez zastavení, konfigurace se zapisovala prakticky výhradně ručně, a admin v bílém plášti a galoších znal všechny konfiguráky i jejich obsah. Podmínky se změnily, ale unixy bohužel ne.
-
Sten (neregistrovaný)
fsync - synchronize a file’s in-core state with storage device
a file = jednoho souboru. Nevím o tom, že by to někdy dělal pro víc souborů (snad kromě sparse files, ale ty opravdu nejsou velké). Jediný možný problém je v tom, že fsync neflushne drive cache, tam je opravdu nutné flushnout všechno a zavolat sync.
Pořád se může stát, že smáznete starý konfigurák, ale už nestačíte přejmenovat ten dočasný na nový.
Houby, funkce rename je atomická.
-
Lael Ophir (neregistrovaný)fsync sice provede flush jednoho souboru, jenže řada FS (by default ext3) se snaží zapisovat data na disk v pořadí, ve kterém proběhly zápisy. Jinými slovy pokud vytvoříte A, přejmenujete B, a modifikujete C, tak fsync(C) vede k zapsání akcí provedených nad objekty A a B. A protože write cache může být plná různých věcí, a fsync je synchronní volání, tak vaše aplikace bude celkem dlouho čekat, než se dostane znovu k lizu.
Funkce rename je atomická, ale bohužel unlink(a);rename(b) atomické není. Ve Windows být může, ovšem to jsme vývojově o 10+ let jinde. U konfigurační DB, která tenhle problém nepotřebuje řešit, pak o 20+ let jinde. -
Lael Ophir (neregistrovaný)Bohužel nejlepší možný stav je pořád mizený. fsync() trvá na některých FS velmi dlouho, přepisování konfiguráků kvůli změně jedné hodnoty je zbytečně dlouhé. Oni 10+ let před příchodem Windows měli implementovat konfigurační DB (a GUI, a tisk, a rozumné high level knihovny), a ne se prát o koryto a začínat unix wars ;)
-
Milan Keršláger. (neregistrovaný)Odložená alokace znamená, že datové bloky jsou na disku alokovány až ve chvíli, kdy jsou připravena data k zápisu. Dosáhne se tím toho, že lze alokovat více bloků najednou (a ty mohou být souvisle za sebou), takže je pak nižší fragmentace a snižuje se počet nutných I/O, kvůli čemuž ext4, Reiser4, XFS, ZFS používají větší buffery. Data v bufferu (cache) jsou na disk zapsána, když je flush démon na disk vysype, což je standardně tuším 5 vteřin. Tato doba se v nových distribucích (jádrech) prodlužuje, aby se dosáhlo úspory (třeba notebooky). Popsaný jev tak může být v ext4 zvýrazněn (chybí celý soubor a ne jen jeho část), ale bude se vyskytovat i v jiných systémech souborů. Chyba je jednoznačně na straně aplikace, která by měla nejprve zapsat nový konfigurační soubor a teprve pak starý smazat a nový přejmenovat (a akci si na konci třeba pojistit pomocí flush).
