Matthew Garrett az alkalmazás-fejlesztőkről, fájlrendszerekről

Fájlrendszer, NAS, storage

Matthew Garrett - egykori legaktívabb Debian közreműködő - is beszállt az össznépi ext4 késletetett allokáció vs. 0 hosszúságú fájl adok-kapokba.

Garrett szerint az alkalmazás írók nagy része számára teljesen haszontalan oly módon fájlrendszert tervezni, amelynek értelmes felhasználása lehetetlen, még akkor is ha egyes esetekben ez a módszer a teljesítmény javulását is hozhatja.

"Kedves fájlrendszer írók - az alkalmazás-fejlesztők szeretnek sok apró fájlt írni, mert ez nagyon sok dolgot jelentősen egyszerűbbé tesz. Ez rendben van, mert a puszta fájlrendszer teljesítmény nincs magasan a tipikus alkalmazás-fejlesztő prioritási listáján. A válasz nem az, hogy "Oh, mindannyiótoknak sqlite-ot kellene használnotok". Ha csak az adatbázis alkalmazása az egyetlen hatékony módszer a fájlrendszeretek használatára, akkor az azt jelenti, hogy nem írtatok olyan fájlrendszert, amely hasznos a tipikus alkalmazás-fejlesztők számára, akik élvezettel tárolják a dolgokat inkább fájlokban, mint bináris blobokban [...] Ha azt szerettem volna, hogy az összes adatom oracle-ben legyen tárolva, akkor a kezdetektől fogva nem lenne szükségem kib.szott fájlrendszerre, nem?"

A teljes blogbejegyzés itt.

( korci | 2009. 03. 16., h – 14:01 )

Hogy mennyire haszontalan az egy dolog, de abban igaza van (szerintem), hogy ha kerítést akarok festeni a fájlrendszeremmel (mint az emberek 90%-a), akkor nem érdekel, hogy mennyire gyorsan magozza a meggyet, ha cserében necces a festés.

Képletesen értve. Azt ne mond, hogy komolyan elgondolkoztál... :) tipp: "Kerítés festés" alá helyettesítsd be a manapság leggyakrabban elvárt funkciók bármelyikét, "meggymagozás" alá pedig valami olyat ami teljesen új, Generation X feature, csak éppen nincs rá mindenkinek szüksége.

Remek, pont ezt szerettem volna elérni elsőre is. :) Nem akartam megismételni az eddig xy db fórumon az unalomig átbeszélt f*sync-es vagy f*sync-telen probléma kivesézgetését (ami véleményem szerint kicsit talán túl is van már hipe-olva), csak szerettem volna jelezni, hogy egyetértek a hírben szereplő illető megjegyzéseivel.

Ok, the az O_TRUNC-al nyomulsz, akkor ez elvileg barmikor megtortenhet amugy is, sot ha jol remlik POSIX dolgoknal is le van irva fs-sel kapcsolatban hogy vannak nem igazan definialt allapotok. Ha barmi cucc van ami ujrair egy file-t hogy van egy allapot, amikor a file merete nulla, hat akkor nem kell csodalkozni, hogy elvileg pont ott bedolve a dolog nem is marad belole semmi. Ez ellen tenyleg ugy kene vedekezni hogy elkerulni a nem definialt allapotokat (pl igen, temp file-ba letenni, aztan rename-elni a regire), vagy definiciot keresni arra, hogy mi legyen ilyen esetekben, hiszen ezt nyilvan minden fs "szerzo" ugy implementalja ahogy akarja, ha nincs ra szentiras, hogy ilyenkor mi tortenjen ...

Világos. A lényeg viszont, hogy az alkalmazások alá kell fájlrendszer, és nem fordítva. Nem azt mondom, hogy ész nélkül kell fejleszteni, de semmit nem ér az esetleges sebesség, ha biztonságosabb nem használni. Tudom, hogy ez nem újdonság, de ezért használok még mindig ext3-at (valahogy nyugodtabban alszom tőle). Persze ha videót vágnék, akkor lehet, hogy pont erre (ext4) lenne szükségem, meg egy jó kis szünetmentesre.

Igen, de honnan tudjam, hogy mikortól kell várni? Ha a házat nézem, akkor az látszik, hogy egy üresjáratban lévő desktop is használja a lemezt néhány másodpercenként, egy szerver meg főleg. Itt nem az a gond, hogy az általam szerkesztett dokumentum veszne el (erre elég kicsi az esély), hanem, hogy olyan konfigurációs és logfile-ok nullázódnak, amiket a rendszer az én közreműködésem nélkül ír felül tetszőleges időpontokban.

Egy szerveren ez ciki, de a mezei user sem örül, ha újraindításkor nem indul a gnome v ópenoffisz, mert az alkalmazás épp áramszünetkor írta ki a configfile-át.

Én ebben a nagy flame áradatban csak azt nem értem, hogy világosan látszik, hogy az alkalmazásfejlesztők azok akik ész nélkül fejlesztenek.

Elég egyértelmű, hogy ha valami kritikus, akkor arra fsync, ha meg vmi. "mennyiségi" adat, akkor nem kell rá fsync, mert nem gáz ha elveszik.

Az egyetlen, ami miatt néhány alkalmazásban semmire sincs fsync, az a fejlesztők trehánysága.

( uid_14357 | 2009. 03. 16., h – 14:55 )

Aha, csak az sqlite olyan I/O terhelést ad, hogy öröm nézni ahogy a gép "megáll" az iowait-ek miatt.
Lásd firefox3, liferea...
--
\\-- blog --//

En kiprobaltam az sqlite3-t spamszuresre (egy halom tokent tarolva benne), de csak select-eket adva ra, es semmi gubanc nem volt vele*. Bar azt hallottam, hogy ~180 MB meret korul azert mar nem olyan gyors....

*: PRAGMA synchronous = OFF pragmat hasznalva

SPAMtelenul - POP3 spamszuro szolgaltatas

A liferea* csinál olyat ~30 feed felett, hogy átlag 500-1500 kbyte/s read és 300-400 kbyte/s write "terhelést" okoz** miközben egy körülbelül 10MB méretű db-vel dolgozik, így körülbelül 2-4 perc míg elindul*** és betölti a feedeket, ezután jön a frissítésük :D

Az egész könyvtárát tmpfs-re rátolva a fenti művelet gyakorlatilag másodpercek alatt végbemegy.

*gnome-os rss reader
**Ezeket iotop-pal mértem.
***5400rpm laptop diszk
--
\\-- blog --//

( Yorirou | 2009. 03. 16., h – 15:13 )

Na végre :)

"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."

( mrev | 2009. 03. 16., h – 15:43 )

open(), write(), fsync(), close()

Tegnap mászkáltam a tv-csatornák között, véletlenül hallottam ezt:

Telefonálnak:
- Bólints, ha beleegyezel.
- Bólint.
- És most szólj, hogy bólintottál-e az előbb.
--
CCC3

( vomberg | 2009. 03. 16., h – 16:41 )

Az én olvasatomban egészen másutt van a probléma gyökere.

A filerendszerek hatékonyságnövelése már csak azon az áron megy, hogy akár 5-10 percig is "szakadék fölött" lebegnek az adataink, miközben már rég biztonságban hisszük őket. A kulcs az alkalmazásfejlesztők kezében van, csak ugye ez az elmúlt 40 évben nem jelentett problémát, a filerendszer fejlesztők meg nem tartottak egy általános figyelemfelhívási kampányt, hogy "paradigma váltásra lesz szükség az alkalmazások fejlesztésénél, azaz a fontos adatokat sync-elni kell". Ugyanis eddig nem volt ilyenre szükség lassacskán viszont egyes helyeken lesz. Igen, ezt is meg kell tanulni, hogy mikor melyik fileműveletnél kell meggyőződni arról, hogy valóban kiírta a rendszer az adathordozóra.

Ezzel semmi gond, mindig vannak új tanulnivalók, a gond csak ott van, hogy erről nem szólt senki, hogy ilyen banánhéjat csempésztek be a talpunk alá!

[irónia]Dehát ha olvasod a kernel forráskódját, akkor egyből látszik. Nem is értem, hogy minden alkalmazásfejlesztő miért nem olvassa a kernel forráskódját, ha már egyszer arra a platformra fejleszt.[/irónia]

"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."

Igen.

Asszinkronná változtatni egy függvényt ami addig nem az volt, felelőtlenség, mert az összes eddigi program működésére kihat.

A helyes megoldás az, hogy amely utasítások korábban szinkron módban futottak - azaz a program csak akkor lépett a következő utasításra, amikor az előző utasítás hatásai létrejöttek - azok így is maradjanak!

Ha megjelenik egy új funkció mint most: adott hatást asszinkron utasítással is kérhetek, akkor az ezzel járó függvények kapjanak új neveket!

De most még aszinkronabb lett, mert eddig az garantált volt hogy újraíráskor a meglévő adatok nem vesznek el, mostantól meg ennek biztosítása eddig nem igényelt szinkronizációs lépést igényel.

Azaz eddig a felülírás szinkronizált volt addig a pontig, hogy a régi adatok kiírodnak, és csak az új adatok kiírása volt aszinkron.

Melyik a fontos adat? Szerintem mind fontos. Akkor ezentúl mindig syncelni kell? Ha igen, akkor a filérendszer fejlesztőknek nem sikerült hatékonyabb rendszert tervezni.

Nem az számít, hogy nehéz volna az alkalmazásokban syncelni, hanem vagy fejlődés, hatékonyság, késleltetett allokálás meg effélék, vagy syncelés. Elég nevetséges, hogy a syncelést ajánlják. Ellentmond annak, amiért dolgoznak.

Amúgy túl van dimenzionálva a probléma.

A Micimackóban Bagoly házán van egy csengő és egy kopogtató. Az egyiken a felirat: Ha azt akrj, hgy knyssk kpgttni tssk. A másikon: Ha nem akrj, hgy knyssk csngtn tssk.

Na, ez a megoldás. Kell egy write1 függvény, ha azt akarjuk, hogy az adatok kiíródjanak, és kell egy write2 függvény, ha azt akarjuk, hogy az adatok ne íródjanak ki:)

CCC3

Nem jól fogalmaztam, ha az jön le belőle, hogy aggódok a sync hiánya miatt.

Még a múlt évezredben az akkori macskám egyszer végigment a Netware szerver (4.1) billentyűzetén. A szerver összeomlott és a rajta levő fájlrendszer elromlott. Megmaradtak a fájlok, de a directory struktúra megszűnt, az összes fájl valahogy a gyökérbe került. Újra kellett az egészet installálni. Ilyen izéken tárolták akkoriban a "fontos" adatokat. Ehhez képest ... éntőlem nyugodtan allokálhatnak késleltetve.
--
CCC3

Lehet 0 bytost file-t NTFS-n is létrehozni.
Egy file rendszer összeomlasztásához nem kell tudni annak a forrásódját olvasni.
Emlékeim szerint az "ellenségnél" hogy legyen e sync vagy nem ,az dönti el ,hogy a hordozót gyors írásra
vagy gyors eltávolításra csatoltad fel.
Bár egy kernel színű fagyástól ez sem óv meg.

Nekem eddig egy fajlrendszerem szallt el "magatol", es ez pont NTFS volt.
Az igazan vicces az volt benne, hogy a konyvtarakat csak az "s" betuig lehetett olvasni, utana nem. Igy le tudtam menteni minden adatomat amelyik abcben elorebb volt az "s" betunel. Termeszetesen a windows nem indult el, mivel nem latta a "system(32)" konyvtarat;)

De ettol meg lehet jo, meg szuper, ez csak egy pelda. Igaz azota se tartok fontos adatot NTFS-en, legyen akarmilyen biztonsagos.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( asch v | 2009. 03. 16., h – 18:56 )

Szerintem:
1. Teljesen igaza van Ted Ts'o-nak. Ha nem a specifikációnak megfelelően használunk egy API-t, ahogy a fájlrendszert úgy használták, hogy definiáltan definiálatlan állapotokra bízták az adat integritását, akkor ők a ludasak és neki ezzel semmi dolga nincs.
2. A felhasználónak aki rinyál hogy ez regresszió igaza van. A regressziót a fájlrendszer változása hozta, tehát jogos hogy a fájlrendszert hibáztatja. Jogos, de nincs igaza :-).
3. Az alkalmazásfejlesztőknek nincs igaza. Elrontották ahogy használják a fájlrendszert. Most meg pampognak hogy nem működik aminek nem is kellene működni.

A megoldás viszont nincs tekintettel az igazságra. Első lépésként alapértelmezetten tiltani kell az aszinkron írást, de közben rávenni a fejlesztőket hogy rázzák gatyába a fájlkezelésüket.

Általános esetben megoldani hogy minden konzisztens maradjon baromi nehéz feladat. Végleges megoldást csak a fájlrendszerbe épített tranzakciókezelés ad.

Az fsync-es megoldás már csak teljesítmény szempontból sem jó, mert amit nyerünk a késleltetett kiírással azt elveszítjük az fsync-nél amint az összes programba tisztességesen bekerül a hívás.

"Az fsync-es megoldás már csak teljesítmény szempontból sem jó, mert amit nyerünk a késleltetett kiírással azt elveszítjük az fsync-nél amint az összes programba tisztességesen bekerül a hívás."

Nem feltétlen, mert pl. gcc minek hívna fsync()-et egy új object file kiírása után?

Mamrint linux-nal? Szamit? Nem ext4 lesz, hanem next4, aztan jonapot. Eddig meg csak a postfix eseten hallottam, hogy vmelyik filerendszerrel ismetelhetoen gondja lett volna egy user space-ben futo programnak (ettol persze meg lehet ilyen), igy nincs nagy szukseg kompatibilitasra. Persze, lesz akinek nem fog tetszeni /hatalmas tarterulettel, es hasonlok/, de az marad a "regi" fs-nel.

Miről beszélsz, milyen inkompatibilitás? Egy alkalmazásnak tökmindegy, hogy extN, xfs, reiserfs vagy jfs van alatta, ugyanazokkal a függvényhívásokkal írja-olvassa őket.

Egy valamirevaló alkalmazásnak nem csak egy adott filerendszer + mount opció kombináción kellene megbízhatóan működnie. Tehát hiába jön el egy tranzakciókra képes filerendszer API, amíg a mostani "hagyományos" filerendszerek ki nem halnak, addig támogatni kell őket.

Nem beszélve arról, hogy hogyan használnának a mélyen tisztelt "application developerek" egy ilyen tranzakcionális API-t, amikor egy nyamvadt fsync() ekkora értetlenséget és ellenállást vált ki belőlük.

A "visszafele" kompatibilitasrol. Nem kell kompatibilisnek lennie az ext4-nek, az ext3-mal, csak ha kijelentik, hogy az. Ha mashogy hivjak, es nem asszicial tole az ember az ext sorozatra, akkor nem is elvaras. A tobbi fs-sel arra probaltam celozni, hogy _nem_ kompaitibilisek egymassal, nem volt cel, es elvaras sem.

( skynetpro | 2009. 03. 16., h – 23:31 )

most mit kell ezen flémelni

akinek kell a performansz, az vesz egy szünetmentest és használja az ext4-et és örül.
aki meg nem vesz szünetmentest, az meg marad az ext3-nál, ennyi.

Sajnos itt a szünetmentes sem segít minden esetben.
Nekem van szünetmentesem, de néha előfordul, hogy úgy lefagy a gép, hogy nem tudom sehogy újraindítani, ilyenkor jön a hard reset.
Illetve volt már olyan áramszünet is, amit nem tudott lekövetni a szünetmentes, 4-5 másodperc hosszan nagyon gyorsan, felváltva ment el, jött meg az áram.

( dii | 2009. 03. 17., k – 00:49 )

Az én tenyeres talpas paraszt eszemmel csak azt nem értem, hogy az előző postban az volt, hogy nem tudja mennyivel lassabb ha át van kapcsolva másik üzemmódra. Hogy a rákba nem tudja? 20-30%-ról vitatkozunk itt vagy 500%-ról?

Mert szerintem nagyon nem mindegy. Most hogy talán lassan elindul végre az SSD is normálisra, a leglassabb alkatrész (vinyó) is hasonló sebesség változáson megy át mint a gép többi része, akkor itt akár 200% plusz sebesség is jöhet egy év alatt simán. Innen meg pont hogy lesz*rom hogy mennyivel lassabb ha tuti biztonságos.