Ext4 bug: Hrozí ztráta dat (diskuse)

[wire64]

Všem uživatelům Ubuntu 9.04 gratulujeme

[belisarivs]

Dekuji. Na Ext3 si nemuzu stezovat.

[Jarda]

Ext4 si můžeš v 9.04 při instalaci zvolit, nikoliv musíš...

[pavlix]

Proč všem? :)

[Shadow]

Bug se ovšem projevuje i u dalších distribucí (v diskusích zaznělo Gentoo), takže proč zrovna Ubuntu?

[Jury]

Na rozdíl od jiných pofidérních distribucí bude v Ubuntu jako defaultní volba ext3 ještě víc, než půl roku... takže kde je problém? :)

[Wire64]

Pomineme-li různé hard-core distra typu Gentoo nebo Arch, vsadíme se, že Ubuntu bude (hned po Fedoře, u které se to dá tradičně čekat) první, které Ext4 nasadí jako default?

[stativ]

No, řekl bych, že u Archu to zas tolik neplatí. Myslím, že tam Ext4 nebude default ještě dost dlouho.

[David Watzke]

U Gentoo žádnej default neexistuje, tam ti do toho nikdo nebreptá.

[Michal Fecko]

A je to tu!

[Jardík]

Aha, už chápu, proč se po zatuhnutí (IMHO to bylo krátce po zapnutí) compizu po tvrdém restartu smazalo nastavení firefoxu a proč mi Arch po výpadku energie chcípnul. Jak si to vůbec můžou dovolit nechat být a neopravit to v 2.6.29.

[AHAHA]

S tim FF je to chyba FF, taky se mi to stalo a to bez rebootu.

Ve zpravicce se rika, ze dojde ke ztrate dat, ktere se prave upravuji - myslis, ze pri bootu jadra se taky pousti firefox? :D

Jak si to vůbec můžou dovolit nechat být a neopravit to v 2.6.29.

Vis, ani opravy nemusi byt vzdy trivialni a je nutne je poradne otestovat (u FS obzvlast) - neni pak nic horsiho nez oprava, ktera problem resi jen z casti nebo jej transformuje do jine chyby.

[Michal Fecko]

... a uplne nejhorsie je prist na chybu o ktorej existencii nemate ani paru...

[Michal Fecko]

obsahuje bug, kvůli kterému můžete přijít o důležitá data.

Pravda za predpokladu ze nejake dolezite data tam mate Ja mam na disku take 2 zaujimave testovacie subory - ext4_test.img a btrfs_test.img

[majvan]

Ano, ale priznajme si: ma sa to stat v Microsofte, aj ked len par dni po uvedeni, ci pred uvedenim a mat od nich odpoved, ze to zafixuju az v SP1, tak to by sa vzniesla kritika typu "MS ako vzdy: nekvalitny softver a ani opravit chybu nedokazu..."

[Michal Fecko]

Cize Ubuntu 9.04 uz to opravit nestiha?

[Aleš Kapica]

Ubuntu opravuje nějaký jaderný kód?

[V3N3C3D]

Ale v Ubuntu není jako hlavní FS EXT 4, ne?? Ubunu jse, naposled používal asi ped půl rokem a myslim si, že když se objeví oprava tak to zahrnou do aktualizací!! ;)

[pavlix]

Má se to stát jim, tak buď řeknou, že to neni bug, ale pomluva... nebo řeknou, že to opravili :).

[Jirka]

Ovšem stejně by si uživatelé museli počkat na druhé úterý v měsíci, že.

[majvan]

Samozrejme. Len clovek by teraz cakal, ze aj na linux sa znesie vlna kritiky. Zatial som si tu vsak precital komentare v zmysle "fajn, ja ubuntu nepouzivam!", "ja aj tak pouzivam ext3" atd. To len kvoli objektivite, ako dokazeme Microsoft pospinit kde sa len da ("nikdy nerobil kvalitny kod", "nie su schopni vyriesit problem" atd), pricom ak ide o linux tak sa vyhybame podobnemu konstatovaniu ako mozeme. Fakt si neviem predstavit, co by sa pisalo, keby sa zistilo, ze produkt Microsoftu moze vymazat dolezite data na disku.

[Nikola Ciprich]

jeste jednou, prectete si prosim odkazovanou diskuzi, pokuste se porozumet o co vlastne v tomto pripade vubec jde a pak komentujte. v ext4 NENI primo chyba ktera by zpusobovala nejakou ztratu dat, je to cele trochu slozitejsi. a ano, vyvojari (presneji Teo Tso) dost aktivne pracuji na reseni...

[majvan]

Pozrite sa na to inak. Ak by to takto Microsoft komentoval problem, tiez ho budete ospravedlnovat? Este raz: je tu problem, ktory treba vyriesit, nevyriesi ho uzivatel (BFU), chyba je na strane programatorov/vyvojarov. Nikoho nezaujima, tak ako v pripade podobnych kauz s Microsoftom, ze ta chyba vobec nie je v EXT4, ale v zlom spravani sa aplikacii. Preco jedno ospravedlnujete a druheho by ste nakopali do zadku (poprosim, nevztahovat na seba)?

[Deleted [8409]]

+1 Souhlas

[Xerces]

Tak pokud nikoho nezaujima, tak ako v pripade podobnych kauz s Microsoftom, ze ta chyba vobec nie je v EXT4, tak to stejně můžeme hodit na Microsoft ne? Prostě buďto jste schopen rozlišit v čem je problém a kdo by měl být zodpovědný za jeho řešení a nebo nejste a pak můžeme házet špínu na MS že to je jeho vina

[Aldagautr]

tak ono to ext4 neni zatim vydavano za uplne stable a krom toho je v linuxu jaksi vetsi vyber z moznych filesystemu, nez jen z ntfs, jak tomu je u windows, ze

[majvan]

No lenze ten problem sa neprejavuje len pri ext4, vsakze... Naviac ext4 sa uz ma dodavat s najnovsim kernelom, takze Vasa poznamka nie je celkom na mieste. Inak teraz ste predviedli dalsi priklad, ako sa da vyhnut kritike. Casto sa stava, ze niekto pise, ze ma problem. Diskusia skonci tym, aby nepouzival distribuciu A, lebo v distribucii B to funguje. Ked ma niekto iny problem s distribuciou B, staci mu poradit distribuciu A.

[Aldagautr]

zkus si napred najit duvody, proc se tam ext4 dostalo

[majvan]

Ked si ich najdem, vysvetli to, preco mate nerovnaky pristup k chybam od MS a od linuxu?

[Jardík]

Jenže NTFS je kvalitnější jak všechny linuxové FS dohromady.

[Aldagautr]

I.) mimo misu

II.) blabol

[Filip Jirsák]

Docela by mne zajímala chyba, která by způsobovala, že přijdete jen o data, která zaručeně nejsou důležitá...

[razor]

Tak takovou chybu bych si hýčkal a periodicky vyvoláva :)

[Nikola Ciprich]

Nez tady zacnete vykrikovat "zasvecene" komentare, doporucuji precist diskuzi at nevarite z vody

Zvlaste tyto dva vysvetlujici komentare:

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54

Jinak chyba samozrejme bude opravena, jak v distribucich (napr do sminovaneho ubuntu uz se nejake patche dostaly), tak nejspis i v opravnych radach kernelu.

PS: wire64 - nechces uz konecne pouzivat jen jednu prezdivku at te nemusim blokovat kazdy tyden znovu?

[frr]

Ano, tyhle linky jsem chtěl taky citovat.

A především: tohle není jednoznačně bug v kernelu. Jedná se spíš o bug v aplikacích, které nevhodným způsobem pracují se svými konfiguračními soubory (neustále je mažou a znovu vytvářejí), a díky tomu jsou choulostivé na opožděný zápis - což je jinak velice bohulibá vlastnost VM a FS, kvůli průchodnosti diskového subsystému a třeba kvůli spotřebě notebooků. Označovat toto za chybu v kernelu je podle mého poněkud přehnané. Jedná se o nové chování, které odhalilo, že starý císař (aplikace) je nahý. Ostatně i zmiňované "patche" do kernelu jsou ve skutečnosti spíš kernel-space workaroundy, které se na bázi jakési heuristiky snaží odhalit provinilé aplikace (problematické chování) a provést jakási protiopatření (dané soubory flushovat častěji, než by podle POSIXu bylo potřeba).

Je docela nešťastné, že provinilými aplikacemi jsou zrovna desktopová prostředí. Takže kvůli ztrátě pár souborů při softwarovém zatuhnutí systému se člověku rozsype desktop...

[pavlix]

hmm, zajímavé... pořád lepší než aby se ztratila důležitá data, ale

[default]

No, já osobně o tom vím kulový, ale z mého pohledu nevidím nic špatného na mazání a vytváření souborů. Podle mě je tento přístup mnohem efektivnější, než v aplikacích řešit nějaké mergeování dat pomocí nějakých šílených seeků. To, že se žurnál nedokáže vyrovnat se smazaným a znovu vytvořeným souborem, je podle mého názoru chyba žurnálu — nikoli chyba aplikace. Navíc, v životě jsem neslyšel o nějakých limitech na počet přepsání souborů za jednotku času.

Samozřejmě netvrdím, že když si pustím textový editor na pozadí a stokrát ve vteřině mi bude přepisovat nějaký soubory na disku stejným obsahem, že je to v pořádku.

[Filip Jirsák]

Alternativou k mazání a vytvoření není mergování, ale přepsání existujícího souboru. Smazání a znovuvytvoření souboru se stejným jménem je vlastně takový podvod -- a navíc se tím rozbijou přístupová práva, rozšířené atributy nebo pevné odkazy.

[Jan Kundrát (jkt)]

Pokud potrebuji nejaky soubor bezpecne prepsat, je mnohem lepsi nekde stranou vytvorit soubor novy a data zapisovat do nej. Tvrdi to i Ted Tso.

[Filip Jirsák]

Jistě, přejmenování je atomická operace, to má jistou výhodu. Ale vytvoření souboru a jeho přejmenování na původní název není operace totožná s přepsáním souboru, což si bohužel asi spousta programátorů neuvědomuje. Když vám taková aplikace znemožní používat pevné odkazy, budete mít na výhodnost vytváření nového souboru jiný názor.

[default]

Dokud nebude file systém transakční, pak mají uživatelé linků smůlu.

Jen podotýkám, že sám jsem tohoto chování zneužil při integraci systémů v jedné z největších Českých bank, a dosud si nikdo neztěžoval. (To jen pro úplnost).

[Filip Jirsák]

Takové aplikace mám nejraději. Programátor se nechce obtěžovat s tím, aby napsal pořádně zápis konfiguračního souboru, tak rozhodne, že uživatel nepotřebuje rozšířené atributy, linky, přístupová práva k souborům, vrstvené souborové systémy -- prostě cokoli, co jde připojit k node souboru a co daná aplikace nezná a nedokáže to zduplikovat do nového souboru. Tímhle stylem se programuje ve Windows, a pokud se má tenhle styl zanést do OSS, pak děkuji, nechci.

[default]

Takové aplikace mám nejraději.

Já vím.

Programátor se nechce obtěžovat s tím, aby napsal pořádně zápis konfiguračního souboru, tak rozhodne, že uživatel nepotřebuje rozšířené atributy, linky, přístupová práva k souborům, vrstvené souborové systémy -- prostě cokoli, co jde připojit k node souboru a co daná aplikace nezná a nedokáže to zduplikovat do nového souboru.

Já o žádném konfiguračním souboru nemluvil. Tak mi necpi něco do huby. Stačil mi oběd.

Tímhle stylem se programuje ve Windows, a pokud se má tenhle styl zanést do OSS, pak děkuji, nechci.

Však já ti nic nenutím.

[David Jaša]

Jen podotýkám, že sám jsem tohoto chování zneužil při integraci systémů v jedné z největších Českých bank, ...

Které banky mají slovo Česká v názvu?

[thingie]

Hned třeba ta národní

[Luk]

No přece Česká!

[default]

Příště vám nic neřeknu. Když máte možnost se dozvédět něco, co vám pomůže, tak se smějete. Příště se smějte se své hlouposti a možná hlavně neznalosti.

[thingie]

Nic nepsat proti pravopisným chybám pomáhá dokonale, to je pravda.

[default]

Víš, co je nejdokonalejší? Že tenhle portál je ze zahraničí stráááááášněééééé pomaléééj. A když to chci mahlásit jako bugu, tak mi to píše, že něco není košér s mým heslem. Tak já teda nevim…

[Ondrej 'SanTiago' Zajicek]

Nicmene prepisovani souboru na miste je operace mnohem rizikovejsi. Zatimco vytvoreni souboru vedle a nasledne prejmenovani jde snadno udelat tak, aby system byl stale konzistentni jak pro pouzivani tak pri vypadku, u prepsani dat na miste bys kvuli tomu musel delat znacnou magii (implementovat vlastni jurnal?).

[petr_p]

Ano. Ale pokud stojím o zachování atributů? Zatímco vlastní „žurnál“ si přes mandatory locking otevřeného souboru udělat můžu, tak na metadata mě žádný zaručený způsob nenapadá.

[Filip Jirsák]

Startovat jakoukoli aplikaci po tvrdém pádu systému se smetím, které po pádu zbylo, nepovažuju za dobrý nápad. Vždy by se měla prohlédnout konfigurace, zda není poškozená. Takže úplně stačí před úpravou udělat záložní kopii souboru (třeba .bak), a původní soubor pak přepsat. Zajímavé je, že třeba takový vim soubory přepisuje, a přesto obnovu po pádu zvládá velice dobře. Takže přepsání souboru na místě udělat bezpečně jde. Dokonce tím získáte ochranu nejen proti tvrdému pádu systému, ale můžete konfiguraci obnovit i při chybě uživatele (což je daleko častější případ) -- pokud tedy záložní soubor nemažete.

[Jan Kundrát (jkt)]

Na vytvareni a mazani souboru neni nic spatne. Spatne je, pokud aplikace pouziva POSIX rozhrani a pritom spoleha na to, ze se soubor zapise na disk pri volani close().

"Vsechny nove filesystemy" (a to vcetne ext3) data, ktera maji byt zapsana na disk, interne cachuji. Pokud by se tak nechovaly, dostanete z beznych disku maximalne 100 operaci za sekundu. Shodou okolnosti ext3 takova data na disk zapisuje v defaultnim nastaveni kazdych 5 sekund, a proto je riziko "ztraty dat" pomerne male.

POSIX rika, ze pokud je potreba mit data opravdu dostupna na disku, je nutne zavolat fsync() ci jeho alternativy. Pokud si aplikace mysli, ze staci close(), je to problem jeji a nikoli kernelu. Prece kdyz pouzivam nejake API, tak si ho musim precit a posoudit, jak se chova v okrajovych pripadech.

[default]

Znovu upozorňuji, že daný problém se mě netýká a nezajímá mě.

POSIX rika, ze pokud je potreba mit data opravdu dostupna na disku, je nutne zavolat fsync() ci jeho alternativy. Pokud si aplikace mysli, ze staci close(), je to problem jeji a nikoli kernelu.

Když vezmu vpotaz situaci, že korektně používám POSIX… Korektně uložím (konfigurační) soubor a zavolám close(). Pak systém lehne. Nevím, ale měl jsem doteď za to, že žurnál tu je právě od toho, aby zajistil konzistentní file systém. Takže: buď ať je na disku původní verze, nebo nová.

Toto nemá nic společného s tím, zda někdo dokumentaci čte nebo ne. Toto je prostě závažná chyba, když se po zavolání close() (nebo před ním) filesystem rozsype.

Prece kdyz pouzivam nejake API, tak si ho musim precit a posoudit, jak se chova v okrajovych pripadech.

A je někde v dokumentaci napsáno, že když nezavolám sync() byť jsem korektně zavolal close(), že se má filesystem s žurnálem rozesrat?

[Michal Kašpar]

A je někde v dokumentaci napsáno, že když nezavolám sync() byť jsem korektně zavolal close(), že se má filesystem s žurnálem rozesrat?

A kde berete tu informaci, že se fs rozsype? Pokud tomu dobře rozumím, tak pouze přijdete o data souboru. Ale jejich korektnost vám žádný (trochu zevšeobecňuju) současný žurnálovací fs nezajišťuje, ty zajišťují pouze konzistenci metadat.

[alblaho]

Žurnálují se ale jen metadata. Žurnálování dat lze v ext3 zapnout, ale nikdo to nedělá, protože je to pomalé.

[default]

Měli by to zrychlit

[stativ]

To by mi zajímalo, jak bys to chtěl zrychlit. Logicky když ukládám dvakrát tolik dat, tak to bude trvat asi dvakrát tak dlouho.

[M. Lox]

Můžeš použít wandering logs, jako Reiser4.

[alblaho]

Takže Reiser4 žurnáluje i data? To je zajímavé. Btrfs to neumí? Jestli je to takhle řešitelné, tak je docela hloupé, že to umí jen R4.

[M. Lox]

Neznám detaily implementace, ale podle whitepaperů jo. O Btrfs nevím skoro nic, tak nemůžu sloužit.

[Ladicek]

No jo, řešitelné. Ona to ale bude nějaká Hansova úchylná datová struktura, kterou si nikdo jiný netroufne implementovat

[alblaho]

To jsou ty zfetované stromy a COW. Myslím, že takhle nějak je udělané i ZFS.

[petr_p]

Žurnál je z hlediska POSIXu irelevantní. POSIX říká, že po close(2) data na disku uložena být nemusí. Tohle je vlastnost, ne chyba.

Jiná věc je, že žurnál v běžném nastavení je kompromis mezi výkonem a spolehlivostí a neřeší spolehlivost dat – řeší jen metadata.

[default]

Moment! Já měl za to, že je všechno spolehlivý a že všechno přežije případný pád systému! Aha. Asi si budu muset něco nastudovat.

[default]

No já jsem z toho jelen. Už jsem se v tom ztratil. Takže — všichni máte pravdu a já jsem letadlo.

[tom]

A je někde v dokumentaci napsáno, že když nezavolám sync() byť jsem korektně zavolal close(), že se má filesystem s žurnálem rozesrat?

To jste tak liny precist si man 2 close? Tam je uplne jasne napsano, ze zavolani close neznamena, ze se zapsala vsechna data a ze pokud tu jistotu chcete, mate volat fsync().

[default]

To jste tak liny precist si man 2 close?

Líný nejsem. Jen šetřím svůj čas. Informace z odkazované manuálové stránky jsou mi úplně k ničemu.

[Atom321]

Ano a v manuálu fsync je navíc psáno, že fsync nezaručuje zápis položky v adresáři. Nebuďte líný a přečtěte man 2 fsync . Pokud tedy chcete mít ještě o trochu větší jistotu, volejte ještě fsync() nad deskriptorem adresáře.

[tom]

A jak to souvisi s dotazem, zda je to chovani popsane v dokumentaci?

Navic zapis metadat resi journal pripadne fsck pri startu.

[Luk]

Jedná se spíš o bug v aplikacích, které nevhodným způsobem pracují se svými konfiguračními soubory (neustále je mažou a znovu vytvářejí)

To je naprosto standardní feature (nikoli bug). Pokud se to dělá přímým zápisem do souboru, nelze zajistit konzistenci. Zamkne-li se soubor (advisory locking; s mandatory nelze počítat), je po dobu úprav blokován. Kdežto rename() je atomická operace, takže když se vytvoří nový soubor a po dokončení zápisu se přejmenuje na standardní název, je to bezpečné a nezdržuje to v práci. Neškodilo by samozřejmě flushnout ten soubor na disk, je-li důležitý, aby netrčel dlouho jen v paměti.

[Nicky726]

Poučné.

[alblaho]

Hm, konečně chápu špatnou pověst XFS. Lidi také tvrdí, že "ztrácí data", ale bude to spíš zaviněno aplikací.

Btw, bezpečný způsob přepsání souboru:

3.a) open and read file ~/.kde/foo/bar/baz
3.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
3.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
3.d) fsync(fd) --- and check the error return from the fsync
3.e) close(fd)
3.f) rename("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
3.g) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

...celkem sabotuje hardlinky. Stejně všude dělám symlinky.

[Vojtěch Trefný]

Ke všem komentářům o Ubuntu 9.04 -- Ext4 bude pouze mezi podporované souborové systémy, ale jako defaultní zůstává Ext3!

[pavlix]

Zdravíčko, tak jsem si procházel komentáře na launchpadu... a taky vřele doporučuju je přečíst :).

To že je něco v bugzille jádra ještě neznamená, že je to opravdu bug jádra.

Hrozí pouze ztráta dat špatně napsaných aplikací, které neustále udržují systém v nekonzistentním stavu a tudíž není jenom náhoda, že při pádu systému v nekonzistentním stavu jsou.

Data tedy neztrácí ext3, aplikace, která je pravidelně maže a znovu zapisuje... což holt dopadne tak jak to dopadne. Ta "oprava" ve skutečnosti zavádí workaround, který reaguje na tento model chování aplikací a v praxi ho celkem úspěšně napravuje (samozřejmě ne na 100%).

Viz už odkazované linky.

[Lukáš Zapletal]

Co je to za nesmysl? (Nemyslím zprávičku, ale fakt samotný).

Když se chyba týká ext4 i ostatních FS, pak to nemůže být chyba ext4 samotného! Problém musí být v nějakém nadsystému FS - to je jasné. Pokud je to chyba vyskytující se ve všech těchto FS, zpráva by měla mít název "BRFS, EXT4 a XFS obsahují chybu..."

[Michal Fecko]

zpráva by měla mít název "BRFS, EXT4 a XFS obsahují chybu..."

alebo vrstva pre komunikaciu s FS v linuxovom kerneli ma chybu...

[kuka]

Vtip je v tom, ze o zadnou chybu v kernelu nejde, takze titulek je mimo predevsim z tohoto duvodu.

[tezkatlipoka]

no a ona ta chyba ani neni v souborovych systemech. Nadpis tehle zpravy je strasny a tendencne napsany. Podle zpravy se to tyka pouze nekterych aplikaci, a je to spise problem jejich nez souborovych systemu, ale prislo se na to az ted, kdyz FS pouzivaji zpozdenou alokaci.

[..... Izak .....]

No tak tahle novinka je pekna blbost, zadna ztrata dat nehrozi v dusledku spatneho chovani FS. Zde se rika, ze kdyz aplikace neudela fsync, tak jsou bloky dele v RAM a kdyz spadne PC, nebo se vypne proud, hrozi ztrata tech souboru/bloku ... coz je logicke.

Ja kzdopadne doporucuji si vyzkouset JFS, ktery neudela sync snad ani po 5 minutach a kdyz PC vypnu, nejde namountovat a kdyz udelam opravu, mam tam stary soubor, ale jenom, pokud byl maly, pokud byl velky, bude presunut nejspise poskozeny do lost+found.

jinak ext ma vice moznosti nastaveni journalu a jen malo kdo, ma nastaven nejbezpecnejsi mod, protoze je pomaly. Ani journal na jinem zarizeni nema vetsina desktopu nasazenych.

Ja ext4 pouzivam na data a zadne soubory mi nemizi.

Jinak prave proto DB pouzivaji direct zapis, tedy cache si delaji samy a na disk zapisuji primo se syncem, tedy uplne zakazuji cachovani, vetsina FS lze s touto volbou pripojit, ale vykon je zalostny a vhodne je to prave jenom pro DB.

[x]

Za moderni system povazuji ZFS nebo HAMMER a tam tohle opravdu nehrozi.

[alblaho]

...protože necachují?-)

[c3]

no kdyz myslite ;)

[xm]

ZFS se tenhle problém týká také. On to totiž není problém FS, ale špatně napsaných aplikací. Ta zprávička (a její nadpis) je nesmírně zavádějící.

[David Jaša]

Jů, tenhle bug mě trápil od minulého roku čím dál tím víc... Jsem rád, že se o tom ví, i když ten čas opravy by teda mohl být rychlejší...

[Jan Zapletal]

 

Jů, tenhle bug mě trápil od minulého roku čím dál tím víc... Jsem rád, že se o tom ví, i když ten čas opravy by teda mohl být rychlejší...

A hlásil jste to?

[David Jaša]

Ne. Ono se to projevovalo totálním zátuhem při probouzení z disku (ani SysRq se nechytalo) a při dalším bootu jsem měl rozbitý FS. V dmesg po druhém bootu se nebylo čeho chytnout. V kombinaci se zaneprázdněností a nepřístupností internetu to znamenalo, že jsem do linuxu bootoval jenom když jsem potřeboval něco, co v tom druhém systému opravdu nešlo. :-P

[Atom321]

Ve skutečnosti hlavní vinu nese špatný návrh POSIXové funkce close(), která negarantuje uložení dat na disk, jak by každý průměrný programátor očekával. Že to tak není, je prostě špatně.

[Ondrej 'SanTiago' Zajicek]

Problem neni ani tak v close(), jako spis v negarantovani relativniho usporadani ruznych operaci provedenych jednim procesem. Garantovani zapisu na disk po close() by znacne zpomalilo napr. kopirovani mnoha malych souboru. Stejne tak fsync() mezi jednotlivymi operacemi je znacny overkill, ale POSIX asi nejakou jemnejsi barierovou funkci (ktera by rikala, ze operace to teto bariere se neprovedou pred dokoncenim operaci pred tou barierou) nema.

[Atom321]

To je přesně ten problém - POSIX nemá funkce, které by umožnily efektivní bezpečný zápis do souboru. Efektivní to uděláte snadno, bezpečné trochu složitěji a efektivní v rámci zachování bezpečného to nejde skoro vůbec. Trvám na tom, že by to mělo být naopak.

[finn]

Není to prostě špatně. Pokud by garantovala uložení dat, nefungovalo by kešování, ergo by výkon souborových systémů šel oproti dnešnímu stavu rapidně dolů (takový emerge sync by byl záležitostí možná desítek minut).

[marbu]

Nerekl bych. Toto chovani je vyhodne z hlediska vykonu, fs tak ma vetsi moznosti v optimalizaci zapisu. A to ze se funkce close() chova prave takto by programator vedet mel. Ale na druhou stranu je tady videt, jak jednoduche je „ustrelit si nohu“. Az to neni hezke :)

[Atom321]

Integrita dat je téměř vždy důležitější než výkon a "ustřelit si nohu" by mělo stát vývojáře větší úsilí než bezpečné chování. Situace, kdy vám záleží na výkonu a ne na datech, jsou speciální případy a mělo by pro ně tedy být speciální volání. Např. funkce open() by mohla mít flag O_NO_SYNC_ON_CLOSE, nebo O_TEMPORARY_FILE. Něco takového programátor použije vědomě a nemůže udělat chybu (pokud není úplný idiot). Dále evidentně chybí funkce typu "bezpečně ulož všechny uzavřené soubory tohoto procesu", např. po kopírování. Ono urychlit deset bezpečných ale neefektivních programů je nepoměrně snadnější než odhalit všechny potencionálně nebezpečné chyby v jednom superefektivním hyperrychlém a zabugovaném.

Aplikační programátoři jsou většinou nezkušení amatéři, kteří nečtou dokumentaci, snaží se věci udělat jednoduše. Systémoví programátoři (tj. vývojáři kernelu a knihoven) by to měli vědět a při návrhu API to zohlednit tak, aby vždy nejjednodušší aplikační řešení vedlo na bezpečný výsledek.

Tvrzení: "A to ze se funkce close() chova prave takto by programator vedet mel." je hloupá výmluva programátora, který funkci close() špatně navrhl (nebo si na to špatné chování zvykl) a teď se výsledný průšvih snaží hodit na nezkušené kolegy.

[tom]

Vzdyt se o tom v manu primo pise. Pokud programator pouziva funkce, od kterych si neraci ani precist dokumentaci, je to jeho hloupost.

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2).

[Luk]

Integrita dat je téměř vždy důležitější než výkon a "ustřelit si nohu" by mělo stát vývojáře větší úsilí než bezpečné chování. Situace, kdy vám záleží na výkonu a ne na datech, jsou speciální případy a mělo by pro ně tedy být speciální volání.

Tento předpoklad má řadu úskalí. Zaprvé ta výkonová penalizace je v praxi tak brutální, že na výkonu záleží u drtivé většiny dat. Kromě toho, funkce close() je součástí POSIXu a změnit její chování by znamenalo ztrátu kompatibility.

Dále evidentně chybí funkce typu "bezpečně ulož všechny uzavřené soubory tohoto procesu", např. po kopírování.

To by znamenalo udržovat si po libovolně dlouhou dobu seznam všech zavřených souborů procesu a navíc hlídat, co se s každým takovým souborem děje dále. Tedy jestli s ním například nepracují jiné procesy, co s ním dělají atd. Pokud může do téhož souboru zapisovat více procesů současně, jsou jakékoli požadavky na bezpečné uložení bezpředmětné, pokud se týkají určitého procesu. Celé je to nesmysl - buď se bezpečně ukládá jeden konkrétní soubor (ve stavu, v jakém aktuálně je), anebo se bezpečně uloží úplně všechno (sync()).

Aplikační programátoři jsou většinou nezkušení amatéři, kteří nečtou dokumentaci, snaží se věci udělat jednoduše.

Ano, tak jednoduše, že například vůbec netestují návratovou hodnotu tohoto volání (i mnohých jiných - ale u close() je úplný mor). Přitom close() má vždy nejméně 4 chybové kódy. Může se například stát, že dojde místo na disku - uživatel se pak vůbec nedozví, že funkce close() selhala a on přišel o data.

Tvrzení: "A to ze se funkce close() chova prave takto by programator vedet mel." je hloupá výmluva programátora, který funkci close() špatně navrhl (nebo si na to špatné chování zvykl) a teď se výsledný průšvih snaží hodit na nezkušené kolegy.

Funkce close() v současné podobě existuje desítky let, je součástí řady standardů a programátoři jsou zvyklí ji používat. Není důvod ji měnit (a tím zásadním způsobem nabourat kompatibilitu) jen proto, že si někdo nepřečte, jak funkce pracuje.

[Ondrej 'SanTiago' Zajicek]

> Kromě toho, funkce close() je součástí POSIXu a změnit její chování by znamenalo ztrátu kompatibility.

Zrovna zmenit chovani close() tak, ze by uspal dokud se data nezapisou, by ztratu kompatibility neznamenalo, nebot POSIX rika, ze to negarantuje, nikoliv, ze se tak chovat nesmi. I tak by to ale nebyla rozumna zmena.

[Luk]

Ztrátu kompatibility by to de facto znamenalo, jakmile by se dostalo do dokumentace, že to tak Linux dělá. Programátoři aplikací pro Linux by na to začali spoléhat a přenositelnost na jiné POSIX-kompatibilní systémy by šla mezi půlky. Samozřejmě, že většina volání má v některých systémech svá specifika. Ale v tomto případě by šlo o hodně zásadní věc, proto by bylo dost nerozumné vytvářet linuxový úzus jiného chování.

[Ondrej 'SanTiago' Zajicek]

Takze by to znamenalo ztratu kompatibility aplikaci, nikoliv ztratu kompatibility Linuxu.

A programatori i tak casto nepisou kompatibilni aplikace a pouzivaji ruzna GNU ci Linux specifika.

[Atom321]

Zaprvé ta výkonová penalizace je v praxi tak brutální, že na výkonu záleží u drtivé většiny dat.

Výkonová penalizace je snadno odhalitelná a napravitelná - pokud na to API poskytne prostředky.

Kromě toho, funkce close() je součástí POSIXu a změnit její chování by znamenalo ztrátu kompatibility.

Neznamenalo. Funkce close() nezaručuje uložení dat, ale není nikde psáno, že to dělat nesmí.

Dále evidentně chybí funkce typu "bezpečně ulož všechny uzavřené soubory tohoto procesu", např. po kopírování.

To by znamenalo udržovat si po libovolně dlouhou dobu seznam všech zavřených souborů procesu a navíc hlídat, co se s každým takovým souborem děje dále. Tedy jestli s ním například nepracují jiné procesy, co s ním dělají atd.

Ne. To by znamenalo přidat do seznamu všech neuložených souborů (který už beztak existuje) navíc čísla procesů (nebo spíš proccess group), které ho měly otevřený a to pouze do doby, kdy dojde k uložení těch dat.

Pokud může do téhož souboru zapisovat více procesů současně, jsou jakékoli požadavky na bezpečné uložení bezpředmětné, pokud se týkají určitého procesu.

Otevření souboru někým jiným přece přeci z principu nijak neovlivňuje bezpečnost dat, která zapíšete vy.

Celé je to nesmysl - buď se bezpečně ukládá jeden konkrétní soubor (ve stavu, v jakém aktuálně je), anebo se bezpečně uloží úplně všechno (sync()).

Naopak, nesmysl je, že aplikace s právy uživatele nobody by měla při syncování svých dat vyvolat sync cizích procesů. Funkce sync() podle normy POSIX signalizuje operačnímu systému, že má data uložit. Na na jejich skutečné uložení nemusí čekat, úspěšné uložení negarantuje a případnou chybu nijak neoznamuje. Dokumentaci k sync() jste evidentně nečetl, což je podle vaší logiky pouze a jen vaše chyba. Já tvrdím, že je to je nedostatek API, na který jste právě naletěl.

Aplikační programátoři jsou většinou nezkušení amatéři, kteří nečtou dokumentaci, snaží se věci udělat jednoduše.

Ano, tak jednoduše, že například vůbec netestují návratovou hodnotu tohoto volání (i mnohých jiných - ale u close() je úplný mor). Přitom close() má vždy nejméně 4 chybové kódy. Může se například stát, že dojde místo na disku - uživatel se pak vůbec nedozví, že funkce close() selhala a on přišel o data.

Ano, netestování návratových kódů je chyba programátora, o tom není pochyb. Když jste to nakousl - položím záludnou otázku: Pokud close() vrátí chybu, zůstane deskriptor souboru otevřený, nebo ne?

Tvrzení: "A to ze se funkce close() chova prave takto by programator vedet mel." je hloupá výmluva programátora, který funkci close() špatně navrhl (nebo si na to špatné chování zvykl) a teď se výsledný průšvih snaží hodit na nezkušené kolegy.

Funkce close() v současné podobě existuje desítky let, je součástí řady standardů a programátoři jsou zvyklí ji používat. Není důvod ji měnit (a tím zásadním způsobem nabourat kompatibilitu) jen proto, že si někdo nepřečte, jak funkce pracuje.

Ano, funkci close() kdysi kdosi špatně navrhl, nějakým nedopatřením se stala součástí řady standardů a prudí neopatrné programátory už desítky let. To bohužel platí i o spoustě jiných funkcí. Trvám na tom, že je to vada prapůvodního návrhu, který neměl být nikdy standardizován. Dále tvrdím, že popis v dokumentaci není dostatečným řešením tohoto problému, což potvrzují praktické zkušenosti. A stojím si za tím, že přes standardizaci měly být tyto vadné funkce prohlášeny za zastaralé a nahrazeny novými a protože se to zatím nestalo, mělo by se to udělat co nejdřív.

[Luk]

Výkonová penalizace je snadno odhalitelná a napravitelná - pokud na to API poskytne prostředky.

Nicméně při tvorbě aplikace je těžko predikovatelná, protože to programátor nemůže otestovat na všech možných systémech, kde to poběží (různé síťové filesystémy, pomalé SSD apod.).

Ne. To by znamenalo přidat do seznamu všech neuložených souborů (který už beztak existuje) navíc čísla procesů (nebo spíš proccess group), které ho měly otevřený a to pouze do doby, kdy dojde k uložení těch dat.

Problém je v tom, že ten seznam může být velice dlouhý, protože nikde není řečeno, jaká bude perioda automatického uložení (standardně 30 s, ale u notebooku si to někdo může dát třeba na 10 minut). Pokud se v něm bude vyhledávat, pak to znamená ještě nad nimi vytvořit nějaký strom apod., protože v systému mohou být mraky neuložených souborů a procházet je sekvenčně by bylo hodně zdlouhavé.

Naopak, nesmysl je, že aplikace s právy uživatele nobody by měla při syncování svých dat vyvolat sync cizích procesů. Funkce sync() podle normy POSIX signalizuje operačnímu systému, že má data uložit. Na na jejich skutečné uložení nemusí čekat, úspěšné uložení negarantuje a případnou chybu nijak neoznamuje. Dokumentaci k sync() jste evidentně nečetl, což je podle vaší logiky pouze a jen vaše chyba. Já tvrdím, že je to je nedostatek API, na který jste právě naletěl.

Ohledně těch práv je otázka, zda současný stav vadí. Jinak dokumentaci k sync() jsem opravdu nečetl (až teď), protože jsem toto volání nikdy nepotřeboval. Když už jsem měl potřebu vynucovat uložení na médium (které stejně není úplně zaručené - to by ho museli zaručovat i všichni výrobci úložného HW), používal jsem fsync().

Když jste to nakousl - položím záludnou otázku: Pokud close() vrátí chybu, zůstane deskriptor souboru otevřený, nebo ne?

Záleží na tom, jakou chybu vrátí. Pokud je to EBADF (tj. neplatný deskriptor), pak deskriptor zcela logicky zůstává otevřený. Je-li to jiná chyba, pak není stav deskriptoru specifikován - ani v POSIXu, ani v dokumentaci Linuxu. Faktem je, že aktuální implementace deskriptor zneplatní (odstraní ho z tabulky deskriptorů a příslušnému otevřenému souboru dekrementuje počitadlo referencí). Na to se ale pochopitelně nelze ohlížet, rozhodující je to, co je napsáno v dokumentaci.

Ano, funkci close() kdysi kdosi špatně navrhl, nějakým nedopatřením se stala součástí řady standardů a prudí neopatrné programátory už desítky let. To bohužel platí i o spoustě jiných funkcí. Trvám na tom, že je to vada prapůvodního návrhu, který neměl být nikdy standardizován. Dále tvrdím, že popis v dokumentaci není dostatečným řešením tohoto problému, což potvrzují praktické zkušenosti. A stojím si za tím, že přes standardizaci měly být tyto vadné funkce prohlášeny za zastaralé a nahrazeny novými a protože se to zatím nestalo, mělo by se to udělat co nejdřív.

Ve standardech je toho špatného spousta a zasloužilo by to udělat lépe. Ale vždy je lepší postupovat tak, že se vytvoří něco nového, na to se u nové tvorby přechází a to staré se nechává dožívat v současné podobě dožít (jen se to označí "deprecated" apod.). U close() zatím nebyly žádné velké snahy ho nahradit, jiné věci jsou mnohem palčivější.

[Atom321]

Výkonová penalizace je snadno odhalitelná a napravitelná - pokud na to API poskytne prostředky.

Nicméně při tvorbě aplikace je těžko predikovatelná, protože to programátor nemůže otestovat na všech možných systémech, kde to poběží (různé síťové filesystémy, pomalé SSD apod.).

Programátor přeci může říci, jestli mu na daných datech záleží, nebo ne. Jak se s tím OS popere je jeho věc. V nejhorším případě program poběží pomalu, ale bude dělat to, co autor očekával a data nebudou mizet.

Ne. To by znamenalo přidat do seznamu všech neuložených souborů ... a to pouze do doby, kdy dojde k uložení těch dat.

Problém je v tom, že ... v systému mohou být mraky neuložených souborů a procházet je sekvenčně by bylo hodně zdlouhavé.

Přístup typu "aby se to dobře implementovalo" je zdrojem právě takových potíží, které od začátku řešíme. API je potřeba navrhovat tak, aby se co nejlépe používalo a interní implementaci tomu podřídit. Je to těžší, ale jde to a výsledek stojí za to. (Mluvím z osobní zkušenosti.)

Když už jsem měl potřebu vynucovat uložení na médium (které stejně není úplně zaručené - to by ho museli zaručovat i všichni výrobci úložného HW), používal jsem fsync().

Autoři postižených aplikací zřejmě tuto potřebu neměli. Jednoduše nepočítali s tím, že se systém může podělat a data z cache neuložit. Na výsledných potížích tak mají podíl všichni - autor původního návrhu close(), autoři filesystémů i programátoři problémových aplikací. Každý v této řadě dal přednost výkonu před bezpečností uložení. Svádět celou vinu jen na jednoho z nich je nefér.

[Luk]

Přístup typu "aby se to dobře implementovalo" je zdrojem právě takových potíží, které od začátku řešíme. API je potřeba navrhovat tak, aby se co nejlépe používalo a interní implementaci tomu podřídit. Je to těžší, ale jde to a výsledek stojí za to. (Mluvím z osobní zkušenosti.)

Jenže v okamžiku, kdy se navrhuje API operačního systému, je potřeba uvažovat také to, jak často bude určité volání potřeba a zda stejný účel neplní jiné volání nebo kombinace volání. Po takovém volání, o kterém se tu bavíme, zjevně nebyla příliš velká poptávka, protože zatím nikdo vážně nenavrhl jeho přidání do jádra.

Teprve v tomto okamžiku by se začalo analyzovat, co by znamenala jeho implementace - zatím jsme se ale do této fáze ještě vůbec nedostali. Pokud by se volání přidalo "jen pro jistotu" a implementoval se k němu složitý aparát, jen by v jádře přibyla hromada zbytečného kód, který by zabíral místo a požíral výkon. Proto zmiňuji tu implementaci - ne proto, že by bylo složité to implementovat.

Autoři postižených aplikací zřejmě tuto potřebu neměli. Jednoduše nepočítali s tím, že se systém může podělat a data z cache neuložit.

Já jsem měl tuto potřebu také jen velmi zřídka. Také v aplikacích nepočítám s tím, že se něco podělá tak, že to bude nad rámec běžných chyb detekovaných systémem. Jinak bych totiž musel uvažovat nejen možnost ztráty nezapsaných dat, ale i poškození disku, poškození dat přenášených po síti (nad rámec toho, co dokáže transparentně řešit TCP) a mnoho dalšího.

[Atom321]

Jenže v okamžiku, kdy se navrhuje API operačního systému, je potřeba uvažovat také to, jak často bude určité volání potřeba a zda stejný účel neplní jiné volání nebo kombinace volání. Po takovém volání, o kterém se tu bavíme, zjevně nebyla příliš velká poptávka, protože zatím nikdo vážně nenavrhl jeho přidání do jádra.

Bezpečné uložení souboru je potřeba vždy. Poptávka nebyla, protože potíže nastávaly jen vyjímečně a nikomu nestálo za námahu to řešit.

Autoři postižených aplikací zřejmě tuto potřebu neměli. Jednoduše nepočítali s tím, že se systém může podělat a data z cache neuložit.

Já jsem měl tuto potřebu také jen velmi zřídka. Také v aplikacích nepočítám s tím, že se něco podělá tak, že to bude nad rámec běžných chyb detekovaných systémem. Jinak bych totiž musel uvažovat nejen možnost ztráty nezapsaných dat, ale i poškození disku, poškození dat přenášených po síti (nad rámec toho, co dokáže transparentně řešit TCP) a mnoho dalšího.

No vidíte, uvažujete stejně jako já a i zřejmě jako autoři těch "špatně napsaných" aplikací. Všichni používáme funkci close() ne-úplně-správně, přestože víme, jak pracuje. Občas se to nějakému nešťastníkovi vymstí. Ukazovat na něj prstem a křičet: "on si nepřečetl dokumentaci a může si za to sám" je trošku nefér, nemyslíte?

[Luk]

Bezpečné uložení souboru je potřeba vždy. Poptávka nebyla, protože potíže nastávaly jen vyjímečně a nikomu nestálo za námahu to řešit.

"Bezpečné" (absolutně) to nebude nikdy. Vždycky to bude jen bezpečnější nebo méně bezpečné.

No vidíte, uvažujete stejně jako já a i zřejmě jako autoři těch "špatně napsaných" aplikací. Všichni používáme funkci close() ne-úplně-správně, přestože víme, jak pracuje. Občas se to nějakému nešťastníkovi vymstí. Ukazovat na něj prstem a křičet: "on si nepřečetl dokumentaci a může si za to sám" je trošku nefér, nemyslíte?

Jde vždy o to, s jakou úrovní bezpečnosti je potřeba počítat. Tomu se přizpůsobuje implementace. Ale k tomu je pochopitelně potřeba vědět, jakou úroveň bezpečnosti použité mechanismy zajišťují.

Když už se totiž rýpeme v tomto, pak musím připomenout například memory overcommitting. Je-li zapnutý (což ve většině linuxových distribucí je), pak úspěšná alokace nějaké paměti nezaručuje, že ta paměť bude v případě potřeby skutečně k dispozici. Pokud k dispozici nebude, jádro natvrdo sestřelí téměř libovolný proces (na základě skóre), aby paměť zajistilo. Tuto situaci jsem zažil rozhodně vícekrát, než že se ztratila důležitá data proto, že nebyla ještě uložena z paměti na disk a došlo např. k výpadku proudu.

[Martin Mareš]

Pokud se Vám právě disk odebral do věčných lovišť, nejspíš máte daleko větší problémy, než že se jedné aplikaci nepodařilo zapsat data. Příliš tedy nezáleží na tom, jestli o tom jedna konkrétní aplikace ví, spíš je potřeba chybu zalogovat a zpravit o ní všechny uživatele, aby stihli včas utéct

Existují samozřejmě výjimky, kdy se aplikaci hodí přesně vědět, co se nepodařilo (databáze s transakční sémantikou apod.), ale v takových případech bývají programátoři dost chytří na to, aby si fsync zavolali. Rozhodně kvůli těmto speciálním případům nedává smysl zpomalovat běžnou práci s FS.

Ostatně, systém prostě padat nemá. Pokud padá, je něco fatálně špatně. Řešte proto raději příčinu, místo abyste se snažil záplatovat následky. Dokonale bezpečně se systém při pádu nemůže chovat nikdy.

[Grunt]

Může se například stát, že dojde místo na disku - uživatel se pak vůbec nedozví, že funkce close() selhala a on přišel o data.

Nechci do toho kecat, ale nenáleží starost(+ upozornění správce systému, alokace rezerv aby vůbec mohl být upozorněn a něco s tím udělat) o systémové prostředky právě systému? Je sice fajn, že o tom aplikace ví, ale co s tím asi tak aplikace může udělat?

[marbu]

Dát to najevo uživateli. Přece jenom si neumím představit, ze bych např. zapisoval data někam na flash disk a ono mi to zamlčelo, že se zápis nepodařil celý. Jádro se sice stará o zdroje, ale přímo s uživatelem komunikovat nebude.

[Grunt]

Dát to najevo uživateli. Přece jenom si neumím představit, ze bych např. zapisoval data někam na flash disk a ono mi to zamlčelo, že se zápis nepodařil celý.

Vážený uživateli aplikace Mega Super Enterprise, s politováním Vám oznamujeme, že Vaše data byla nenávratně ztracena, poněvadž se nepodařilo uzavřít soubor. Za vzniklé potíže se Vám omlouváme a věříme, že v budoucnosti se již nastalá situace nebude opakovat.

a nebo:

Chyba při uzavírání souborového deskriptoru 0x43. Navrhnout řešení -> Zkontrolujte si dosažení hranice kvóty určené správcem systému a zkuste uvolnit nějaká data na vzdáleném systému. OK -> close_window().

Ale souhlasím, že někdo by o tom někdo informován být měl. (Jen by close() mělo zmrznout a dostat se do smyčky. Pokud jsou data v paměti, tak ještě existuje nějaká naděje - a paměť umírá poslední).

Jádro se sice stará o zdroje, ale přímo s uživatelem komunikovat nebude.

A to je chyba. Už teď se dozvídám, když mi dochází baterie a jiné výjimečné stavy, tak bych se klidně mohl na stejném místě dozvídat, že dochází paměť, místo na disku, kvóta či jiné systémové stavy(resp. že už se vyskytla aplikace, která narazila na problém s alokací systémových prostředků). A u ne-desktopových distribucí by se to mohlo signalizovat správci, popř. uživatelům.

[Luk]

Ale souhlasím, že někdo by o tom někdo informován být měl. (Jen by close() mělo zmrznout a dostat se do smyčky. Pokud jsou data v paměti, tak ještě existuje nějaká naděje - a paměť umírá poslední).

Jak přesně to bude vypadat, je už záležitostí implementace filesystému. Jádro vrátí chybový kód až poté, co proces vyběhne ven z ovladače filesystému (příp. zařízení). Ovladač může být implementován tak, že když zápis selže, zkusí to ještě několikrát s nějakou prodlevou. Nelze čekat donekonečna, paměť patří ke vzácným zdrojům, navíc i ten visící proces by byl problém.

Už teď se dozvídám, když mi dochází baterie a jiné výjimečné stavy, tak bych se klidně mohl na stejném místě dozvídat, že dochází paměť, místo na disku, kvóta či jiné systémové stavy(resp. že už se vyskytla aplikace, která narazila na problém s alokací systémových prostředků). A u ne-desktopových distribucí by se to mohlo signalizovat správci, popř. uživatelům.

Jenže jakým způsobem to hlásit? Obecně například není problém posílat zprávy přes D-BUS, ale i to má jednak svá úskalí (např. problematické použití při vzdálené práci), ale hlavně ty chyby pak nejdou dát do kontextu s konkrétním stavem aplikace. Jen aplikace ví, co přesně selhalo a může to dát uživateli náležitě najevo. Od systému se uživatel nedozví, jestli kvůli selhání třeba jen nemůže provést operaci Undo, anebo zda přišel o nějaká důležitá data.

[Grunt]

Jak přesně to bude vypadat, je už záležitostí implementace filesystému. Jádro vrátí chybový kód až poté, co proces vyběhne ven z ovladače filesystému (příp. zařízení). Ovladač může být implementován tak, že když zápis selže, zkusí to ještě několikrát s nějakou prodlevou. Nelze čekat donekonečna, paměť patří ke vzácným zdrojům, navíc i ten visící proces by byl problém.

Asi jo. Jak tak čtu dál, tak chyba uzavření deskriptoru nutně nemusí znamenat ztracená data. No na druhou stranu opustit alokované, neuložené data a oznámit to s politováním uživateli? To bude ještě pěkný oříšek: It is quite possible that errors on a previous write(2) operation are first reported at the final close().

Jenže jakým způsobem to hlásit? Obecně například není problém posílat zprávy přes D-BUS, ale i to má jednak svá úskalí (např. problematické použití při vzdálené práci), ale hlavně ty chyby pak nejdou dát do kontextu s konkrétním stavem aplikace.

Samozřejmě jsem neměl na mysli přímý kontext, ale když např. bude uživatel vědět, že dochází místo a najednou se nebude dat ukládat a nebo bude vědět, že dochází paměť a nebude se dát alokovat paměť…přece jen už to budou nějaké indicie pro správce počítače či vzdálenou pomoc(a nebo dokonce technicky schopnějšího uživatele). A jak to hlásit? Pro nějaký enterprise systém či embeded zařízení mě napadá syslog (nevím jestli by se už nedal nedostatek systémových prostředků klasifikovat trochu vážněji a odeslat zprávu všem uživatelům systému jako při restartu:"Prosím uložte si všechna svá data. Brzo se něco semele a pěkné to nebude.") a pro desktop by to šlo kupř. přes nějakého notify démona do stejných míst kde se zobrazuje nedostatek energie v baterii u laptopů.

Jen aplikace ví, co přesně selhalo a může to dát uživateli náležitě najevo. Od systému se uživatel nedozví, jestli kvůli selhání třeba jen nemůže provést operaci Undo, anebo zda přišel o nějaká důležitá data.

Já zase zastávám názor, že pokud se to týká systémových prostředků, tak by to měl řešit systém. Když nastane chyba u close() z toho důvodu, že uživatel vyčerpal kvótu a data se drží jen v keších, tak s tím aplikace už stejně nic neudělá (write vracelo úspěch, takže už mohou být data dealokována a pointery ztraceny).

[Luk]

Nevím jestli by se už nedal nedostatek systémových prostředků klasifikovat trochu vážněji a odeslat zprávu všem uživatelům systému jako při restartu:"Prosím uložte si všechna svá data. Brzo se něco semele a pěkné to nebude."

Takže když si nějaký uživatel připojí foťák, zkusí do něj něco zapisovat a už tam nebude místo, tak systém ztropí takový povyk? Vždyť stačí právě jen to, že to oznámí příslušná aplikace.

[Grunt]

To asi ne. Na druhou stranu když pracuju vzdáleně na nějakém VT a na rootu dochází místo? Vůbec nezávidím těm co to řešit musí.

[marbu]

Jádro se sice stará o zdroje, ale přímo s uživatelem komunikovat nebude.

A to je chyba. Už teď se dozvídám, když mi dochází baterie a jiné výjimečné stavy …

Myslel jsem to tak, že jádro nekomunikuje s uživatelem přímo, ale přes nejakého prostředníka, většinou několik. A v tomto případě mi prostě přijde nejlepší řešení, aby se o oznámení postarala přímo aplikace, která to close() volala, i když nebude moct říct nic lepšího, že uzavření selhalo.

[kuka]

To ze programator nevi, jak neco funguje, je pouze a jedine jeho chyba a zodpovednost. Protoze programatori nectou dokumentaci, tak ma nekdo pro ne neco navrhovat tak, aby to i pres jejich neschopnost vzdy fungovalo? Jednak to ani neni mozne, jednak proc hazet perly svinim?

[Atom321]

To že někomu ukradnou auto, je pouze a jedině jeho chyba a zodpovědnost. Protože řidiči neparkují auto do trezoru z celodenním hlídáním, měl by výrobce montovat do aut lepší zámky, aby jim i přes jejich neschopnost auto nikdo neukradl?

[Filip Jirsák]

Nezlobte se na mne, ale pokud někdo píše program, pro který je správné a konzistentní uložení souborů kritické, tak si prostě musí přečíst dokumentaci o tom, jak operační systém se soubory pracuje a co dělají jednotlivé funkce. Ten váš příměr moc nesedí – okamžité ukládání dat na disk není běžný případ, naopak je to specialita. Kdyby bylo běžné zapisovat data na disk ihned, neměly by OS diskovou cache, nebo by jí zapínaly pouze na výslovné přání programu.

[Atom321]

Uložení dat na disk tak, aby nezmizela, není běžný případ? Na tom se, pane kolego, neshodneme.

[Filip Jirsák]

Uložení dat na disk tak, aby nezmizela, není běžný případ? Na tom se, pane kolego, neshodneme.

Uložení dat na disk tak, aby nezmizela v případě, když vzápětí dojde k pádu systému, není běžný případ. Jak už jsem psal, pokud by to běžný případ byl, nepoužívá se pro zápis na disk cache.

[Martin Mareš]

Ostatně, předpokládat, že při pádu systému lze cokoliv zaručit, je poměrně naivní. To zejména na PC-čkovém hardwaru, který v případě ztráty napájení negarantuje prakticky nic. Například se může stát (a občas stává), že různé části hardwaru reagují na pokles napětí různě rychle, takže když napájení vypnete během zápisu na disk, může se zápis povést, ale úplně jinam, než jak si ho OS objednal. V takovém případě nemůže sebelepší OS zaručit nic.

[Jirka]

Už dlouho nikdo nedělal přiovnání s autem?

[thingie]

Tak teď ještě nějaké na pečivo a máme sbírku kompletní (teda, až na Hitlera, samozřejmě).

[Luk]

teda, až na Hitlera, samozřejmě

A profesora. Netrpělivě čekám, kdy se tu objeví dad a svalí veškenou vinu na svého oblíbence

[Grunt]

Přesně. Ale všímáte si, že to je národní sport pouze na tomto portále?

[thingie]

Ne, protože není. Děje se to všude.

[Grunt]

No, nevím. Na jiných portálech jsem moc ještě nebyl nucen konfrontace přirovnávání k autu. Teda co si pamatuju - a že si to pamatuju docela dobře, protože jediné co mě s auty spojuje je taková blbá kartička a většinou počátek přirovnávání v diskusi je pro mě roven zaslání TCP rámce s RST flagem.

[Atom321]

Ano, přiznávám se, můj oblíbený způsob oponování je přirovnávat hloupá tvrzení k autům. Abyste si mě mohl ještě lépe zařadit, prásknu na sebe také, že sportuji méně než bych měl a stravuji se nezdravě. Lidem, kterým dojdou argumenty a snaží se oponenta v diskusi alespoň zesměšnit, občas z legrace nabízím kuchařské recepty. Také někdy se ženou sleduji seriál "Ordinace v růžové zahradě" a nestydím se za to, nosím brýle, nerad myju nádobí, dovedu kotoul vzad a skákat přes švihadlo, ale nevyšplhám po laně, piju radši vodku než rum, na všech počítačích mám Linux, šachy už jsem nehrál přes pět let a neumím pískat na prsty. Také znám recept na výborné špagety se smetanou a žampiony, chcete ho poslat?

[Luk]

Ne, špatně by právě bylo, pokud by se něco takové dělo. Výkon by šel rapidně dolů. Nicméně pokud je takové chování potřeba, novější jádra mají možnost připojit filesystém stylem mount -o flush, což skutečně způsobí, že návrat z close() bude čekat na uložení na médium (používá se pro výměnná média).

[Tom K]

flush je bohuzel specificka a plati pouze pro fat (vfat, msdos).

[Luk]

Ano, to je určitý nedostatek, ale pro účel, ke kterému je určena (tj. výměnná média používající FAT), postačuje.

[Atom321]

... čímž jste popřel své původní tvrzení.

[Luk]

Co jsem na něm popřel? Připojení s volbou flush skutečně vzniklo jako výkonnější náhrada synchronního režimu připojení (sync), aby nebyla ohrožena bezpečnost dat na výměnných médií v situaci, kdy někdo vytáhne USB kabel, vypne foťák nebo udělá nějakou jinou takovou věc, aniž by korektně odpojil filesystém. Neřešil jsem (nikdy mě to ani nezajímalo), zda je to úplně obecná vlastnost nebo je specifická pro některé filesystémy. Pro zamýšlené použití ale funkce postačuje, protože v drtivé většině takových případů se jako filesystém používá FAT a navíc to nemá sloužit k tomu, aby se místo odpojení filesystému rovnou odpojoval kabel (to je čuňárna i ve Windows, kde je funkce "Bezpečně odebrat" - že ji spousta windowsáků k vlastní škodě ignoruje, je věc druhá).

[Atom321]

To ano, ale neřeší to původní problém ztráty dat na ext4. Nicméně i tak je to dobrý tip, který jsem neznal, děkuji.

[Grunt]

Jen jestli to správně chápu: Vytvoří/změní se soubor, zavře se, na disku se to promítne v metadatech souborového systému ale fyzická data se drží v keši a pokud se nestačí sesynchronizovat tak vnikne Sodoma a Gomora. A teď tu hoří flame o tom jestli má close() zaručovat fyzické zapsání na médium a pokud ne, tak má alespoň existovat varianta open volání, která zaručí, že se nebude kešovat(pominu, že něco takového už existuje) a o vině a nevině programátora, kernel hackera a uživatele. Potřebuje můj výrok nějakou korekci?

[marbu]

Já jsem nabyl spíš dojmu, že: Vytvoří/změní se soubor, zavře se. V tomhle momentě ale ještě data nemusí být fyzicky zapsána na disku (nevolalo se fsync()), takže pokud se systém v tomhle stavu sesype, o data dost možná přijde. Pokud by se system nezhroutil, tak afaik defaultně nastavený ext3 nejdřív zapíše data a pak teprv matadata. Dělá se to takto kvůli bezpečnosti: pokud by se nejprve zapsala metadata jak popisujete, pak při prodlužování souboru by se mohly jeho součástí stát nějaká náhodná už dříve smazaná data.

[Ondrej 'SanTiago' Zajicek]

Mimochodem, jestli jsem spravne pochopil ty bugreporty, tak k problemum doslo po prihlaseni do desktopoveho prostredi a naslednem padu. K tomu me napada otazka, ktera se tu jeste neobjevila - proc sakra desktopove prostredi cokoliv zapisuje do konfigurace hned pri prihlaseni, a ne jenom kdyz uzivatel explicitne meni konfiguraci?

[stativ]

Třeba to bylo první spuštění.

[M. Lox]

To by si uživatelé nestěžovali, že jim ta konfigurace zmizela.

[stativ]

Hmm… to mě nenapadlo.