A késleltetett allokáció és a nulla hosszúságú fájl probléma

ez most olyan, mintha nem bug lenne, hanem feature. legalábbis nagyon megmagyarázza hogy jó ez így.
csak a hírt olvastam el, nem jártam utána, szóval csak a fent említettekből szűrtem le a véleményem.

Az "adatvesztés" jelen esetben annyit jelent, hogy csak a nem kiírt adatok vesznek el, ha jól értem.

Vagy összetudja úgy kuszálni a file-rendszer a dolgokat, hogy régi adat is elveszhet?

Az előző annyira nem gáz, tekintve, hogy milyen ritkán van nem szabályos leállás, a második már aggasztóbb.

Érdekes. Szerintem az ext4-ben van más bug is.. a Jaunty (Alpha 6) a telepítés után nagyjából 2GB-ot foglalt a 4GB-jából. Most ott tartok, hogy van 40MB helyem és hal le szépen lassan minden, pedig semmi adat nincs rajta, mivel csak tesztelek ezen a rendszeren..

aptitude clean is volt már, a Janitor-al leszedtem pár régi csomagot, de csak ideiglenes megoldás, mert olyan hamar teli lesz a lemez mintha folyamatosan szívná el valami a helyemet, vagy a hely felszabadítás nem működne jól, esetleg volt 1-2 kissebb áramszünet mostanság azt tett be neki..

Megyek ráengedek egy fsck-t, hátha rendbetesz valamit...

Theo a következőket mondja:
- Ha nem használsz f*sync-et, akkor nincs mód arra, hogy teljes biztonsággal lecseréld egy file tartalmát delayed allocation használatával.
- A delayed allocation azért jó, mert jelentősen növeli a teljesítményt és csökkenti az energiafelhasználást.
- Ha fsync-et használsz, akkor kiütöd a delayed allocation-t, elveszted minden előnyét.
- Ext3 esetén az f*sync botrányosan lassú.

Tehát, ha egy userspace alkalmazás fejlesztője nem használ f*sync-et, akkor ext4 delayed allocation fájlrendszeren, és ZFS, btrfs, XFS esetében is adatok veszhetnek el áramkimaradás vagy összeomlás esetén.

Ha pedig használ f*sync-et, akkor értelmetlenné válik a delayed allocation, rossz lesz a teljesítmény, állandóan felpörög a merevlemez, és ha elvetemült módon ext3-on indítják az alkalmazást, akkor akár percekre megakadhat, ha közben egy nagy file-t is másol a felhasználó.

Nekem egyik választási lehetőség sem tetszik. Ha az alkalmazások elkezdik nyomatni az fsync-et, akkor a teljesítmény érdekében egy üres függvénnyel fogják implementálni, ahogy teszi az OS X. És senkinek nem lehet egy szava sem, ugyanis a POSIX szabvány lehetővé teszi ezt. Theo is mindig a POSIX-ra hivatkozik, hogy a műveleteknek nem kell olyan sorrendben végrehajtódniuk, mint ahogy a programban szerepelnek.

Szóval szerintem oda lyukadtunk ki, hogy a POSIX szabvánnyal azt az egyszerű use case-t, hogy szeretném egy notepad kaliberű programmal egy text file tartalmát módosítani, nem lehet egyszerre biztonságosan és hatékonyan elvégezni. Vagy biztonságosan csinálom rossz teljesítménnyel, vagy gyorsan és utána imádkozva.

Na még egy alap kérdés.

Akkor az ext4 jelen állapotában laptopra kíváló? Áramszünet miatti hirtelen leállás esélye gyakorlatilag szinte 0, ellenben a késleltetett írásnak köszönhetően ritkábban és kevesebbet nyúl a winchesterhez így akkuidő takarítható meg?

Esetleg rosszul értelmezem a dolgokat, vagy nincs túl nagy különbség és nem számít?

Én ezt az egész problémát nem igazán értem.
Segítsetek mit gondolok rosszul.
Az én szememben az nem fordulhat elő, hogy egy ilyen "hibás" mentésnél (csonkolásra nyitás, új adat kiír, lezár) se a régi, se az új tartalom ne legyen meg!
A naplózó fájlrendszer lényege abban kellene legyen, hogy ennek a helyes és gyors menetét biztosítsa.
A naplózó fájl rendszer használhat késleltetett allokációt, tetszőleges sorrendben írhatja ki az adatokat, ahogy neki tetszik, DE!, amíg nem küld a program flush() vagy close() üzenetet, addig ne csináljon semmi visszavonhatatlant!
Ha ilyenkor elszáll a gép, akkor a naplója alapján állítsa vissza az eredeti állapotot! Hasonlóan, mint az adatbázisoknál a tranzakció.
Amit Tso ír a "helyes" fájl írásról, pontosan azt kellene tennie a fájlrendszernek ilyen "hibás" esetben. Tehát, amikor csonkolásra megnyitok egy fájlt, akkor ne csonkoljon, hanem egy új területre kezdje el kiírni az adatokat, és amint jön egy flush() vagy close(), akkor átállítgathatja a linkeket, hogy most már nem ez a fájl, hanem az új az.
Azt szerintem senki sem várja el, hogy egy "tranzakció" (nyitás, írás, zárás) közbeni elszállás esetén az új adatok kiíródjanak részben is a fájlrendszerbe, de azt igen, hogy a régi adatok ne vesszenek el.
Mi a hiba a gondolatmenetemmel?

Én xfs-t használok. Ott pontosan ugyan ez a helyzet. Ott hozzátettek egy egyszerű mondatot a filerendszer használatához. Szünetmentes áramellátás erősen javasolt. Nekem egy notebookom van. Ez igy automatikusan megoldott. De ha valaki minden sebességet maximálisan ki akar használni az előbb utóbb csak a stabilitás rovására fokozható, anélkül, hogy a felhasználónak bármiféle lépést kelljen tennie. Jelen esetben egy szünetmentes táp.

10 éve a Postgres egy nagyságrenddel lassabb volt más adatbáziskezelőknél, pl. a mysql-nél. Írták a readme-ben, hogy ennek az az oka, hogy ők a tranzakciókat fsync-elik, a mysql viszont nem. Configolható volt az fsync, ki lehetett kapcsolni (attól felgyorsult), de ezt nem javasolták. Ezzel szemben a mostani Postgresben az fsync alapállapotban ki van kapcsolva. Változott a koncepció.

Mindezzel csak arra akarok rámutatni: Az fsync kérdés minimum nem egyértelmű, lehet rajta töprengeni. Túlzottan együgyű az az elgondolás, hogy amelyik alkalmazás nem fsynceli a fontos (?) adatait az bugos.

Egyébként, ahogy mások is írták, az fsync sem tudja garantálni az adat végleges rögzítését. Ez a manban is benne van, azt mindig érdemes olvasgatni.
--
CCC3

Komolyan nem értem a problémát. Biztos én vagyok szűk látókörű, de mi a gond azzal, hogy a nem kiírt fájlok tartalmát elveszti a fájlendszer áramszünetkor? Ez mindigis így volt, max most nőtt a valószínűsége, hogy többet várakozik. Na és? Akinek biztonság kell és még a fájlrendszer dokumentációját sem olvassa el és nem állítja be megfelelően a mount opciókat... annak tanulni kell egy kis adatvesztésből.
Ez a probléma nem érint sok programot, nem értem, hogy az említett gnome és kde miért irogat állandóan fájlokat (ez már eleve nem egy szimpatikus ötlet, flash memórián nem kedvező, de a merevlemez ébresztgetésének sem lehet örülni), de ha már így tesz számíthatna az adatvesztésre, mert ez eddig is könnyen előfrodulhatott csak most nagyobb a valószínüsége.
Valaki homályosítson fel.