Tesztelhető az ext4

Kernel

Június elején írtam, hogy "hamarosan megkezdődhet az ext4 filerendszer fejlesztése". Meg is kezdődött, olyannyira, hogy már tesztelhető is, és ha minden jól alakul, akkor 6-9-12 hónap múlva akár már éles környezetben is használható lesz.

Andrew Morton, a 2.6-os Linux kernel karbantartója október 10-én beolvasztotta az ext4 kódbázisát az -mm kernelsorozatba. Ha valaki tesztelni szeretné, annak minimum 2.6.19-rc1-mm1 jelű kernelre lesz szüksége (frissítés: vagy 2.6.19-rc2 kernelre). Az új filerendszer használatához új e2fsprogs kell. Ehhez itt lehet hozzájutni. Az ext4 használatához instrukciókat itt lehet olvasni.

De miért van szükség az ext3 mellett az ext4-re?

Egyebek mellett azért, mert a merevlemezek kapacitása lassan már a terabyte-okban lesz mérhető, és az ext3 nagy valószínűséggel nem fog tudni mit kezdeni a jövő merevlemezeivel. Az ext3 maximálisan 8 terabyte volume méretet támogat, ami nem valami sok. Ezzel szemben ext4-gyel már 1024 petabye-os volume méreteket kezelhetünk. Sokkal barátságosabb, nem?
További jelentős fejlesztés az ext4-ben az "extent" támogatás is, amely segít a fragmentáció megelőzésében.

Az ext4 visszafele kompatibilis az ext3-mal, azaz mount-olható, mint ext3-as filerendszer (hasonlóképpen, ahogy az ext3 is felcsatolható ext2-ként). Ez egészen addig igaz, amíg az ext4-gyel nem használjuk az "extent" támogatást is (és már létrehoztunk az "extent" kapcsolóval mount-olt filerendszerünkön egy file-t). Ha ezt megtesszük, akkor ezt a visszafele kompatibilitást (azaz, hogy az ext4-et ext3-ként is felcsatolhassuk) elveszítjük. Az "extent" támogatás alapértelmezetten nincs engedélyezve az ext4-ben, az külön kell megtenni a mount-olásnál.

(mount /dev/hda1 /wherever -t ext4dev -o extents)

Egyéb infók az ext4-ről itt.

( suti | 2006. 10. 13., p – 18:38 )

sebességről valami? gondolom, hogy nem lesze az extents miatt fregmentáltabb, az már maga egy sebességnövekedés. de ezen felül van-e még valami plusz?

...gondolom, hogy nem lesze az extents miatt fregmentáltabb,...
gondolom fragmentalodasra gondoltal... Szomoru lenne, ha epp az extent-ek miatt lenne fragmentaltabb:
An extent is ... reduces or eliminates file fragmentation
Amugy:
...featuring support for volumes up to 1024 petabytes ... mar ha ez plussznak szamit :-)

Zsiraf

( egmont | 2006. 10. 13., p – 19:20 )

Nem találtam róla infót: ez fogja tudni a nanosec pontosságú időcímkéket?

Több progiba is belefutottunk már, aminek hibás a Makefile-ja, és vagy következetesen, vagy következetlenül néha nem készült el valami, és ez arra vezethető vissza, hogy 1 mp-be túl sok művelet fért bele, simán létrejött két fájl azonos időcímkével, és utána egy másik szabály, aminek valamit még csinálnia kellett volna, semmit sem tett, mert azt hitte, hogy már rendben van az elkészítendő fájl. Sajnos az UHU 2.0-ban a frozen-bubble pont egy ilyen szitu miatt volt hibás (azonos forrásból néha jól, néha rosszul fordult le, az utolsó lefordításkor véletlenül épp rosszul, és csak később vette észre valaki), a Makefile-ban megfelelő helyre berakott sleep permanensen orvosolta a problémát.

Az ilyen heurisztikus kiszámíthatatlan bugok ellen nagy védelem lenne, hogy ha vki az A fájl alapján generál egy B fájlt, akkor biztos lenne, hogy a B újabb az A-nál, nem pedig lutri kérdése, hogy újabb-e, vagy azonos időcímkéjű.

Lehet, hogy ez neked szol: http://kerneltrap.org/node/6776

...
From: Theodore Ts'o [email blocked]
To: linux-kernel
Subject: Proposal and plan for ext2/3 future development work
Date: Wed, 28 Jun 2006 19:55:39 -0400
...
In addition, we are assuming that various "low risk" changes that do
involve format changes, such as support for higher resolution
timestamps, will _not_ get integrated into the fs/ext3 codebase, and
that people who want these features will have to use the
stable/development fs/ext4 codebase.

Zsiraf

Én saját projektjeimben nem is használom már a make-et. Helyette scons-t használok (www.scons.org). Ennek a projektfájlja valójában egy python, míg maga a scons egy python modul. Sok előnye van és vannak hátrányai is a make-hez képest, de amit itt ki akarok emelni az az, hogy nem az időbélyegzők alapján dönti el, hogy valami megváltozott-e vagy sem, hanem a fájlok hash kódja alapján (nem tudom pontosan mit használ, sha1, md5, stb.). Még arra is van lehetőség, hogy külön könyvtárban felépítse a programépítés folyamatát és ne az eredeti forrásfájlokon, hanem a másolataikon dolgozzon.

Azért valljuk be, egy időcímkét megnézni, vagy egy fájl hash-ét kiszámítani igencsak eltérő mennyiségű munka, főleg ha egy hatalmas projektre gondolunk, például egy kde-méretű forrásfa esetén az összes fájl hash-ének meghatározása akár perc nagyságrendjébe is eshet, ami nem túl szerencsés - bár mondjuk elhanyagolható a kde buildelési idejéhez képest :-)))

Na mindegy, igazából nem akarok vitát nyitni arról hogy make vagy scons, a scons-t még nem ismerem, de sok jót hallottam róla. Viszont nekünk, mint disztribkészítőknek a progi buildelési környezete adottság, alkalmazkodnunk kell hozzá (és persze szükség esetén javítani), és olyan build környezetet felépíteni, ahol a fordítás folyamata minél nagyobb eséllyel pontosan reprodukálható, amihez igencsak jó volna a nanosec pontosságú időcímke. Nyilván nincs arra kapacitásunk, hogy mások programjait emiatt portoljuk makefile-ról scons-ra :-)

Ahm, nem tudtam róla. Megértem a szempontjaikat, h miért nem felelt meg nekik a SCons... de nekem ez a CMake egyáltalán nem tetszik, mivel még mindig a jó öreg make-et használja, szóval tulajdonképpen csak egy Makefile generátor.
(SConsnál nem csak a forrásfile-ok, hanem a buildet vezérlő SConstruct/SConscript file-ok, compiler opciók, stbk. is számítanak annak eldöntésekor, hogy valamit újra kell-e fordítani vagy sem, de ha egy build szabály megváltozik, akkor is csak azt fordítja újra, amit a módosított build szabály befolyásolt.)

szerk.: azért jól elmentünk offtopikba (;

( Nagyapa | 2006. 10. 13., p – 19:32 )

"De miért van szükség az ext3 mellett az ext4-re?

Egyebek mellett azért, mert a merevlemezek kapacitása lassan már a terabyte-okban lesz mérhető,..."

Huhhhhh...

Megnyugodtam. Akkor nálam maradhat a Reiser FS 3.6 ugyanis az iciripiciri merevlemezem 80GB mindössze, és talán egy nagyobbacska 120-160GB-sre fogom (talán) lecserélni. Ha, lecserélem.

Hányan gondolkoztak hasonló módon a 80-as, 90-es években, amikor a programjaikban a dátumban az évet csak két számjeggyel ábrázolták. Aztán ment a kapkodás 1999-ben hogy ezeket javítsák.
Másrészt nem ártana tovább látni a saját desktop PC-nken. Linux kernelre alapozott kereskedelmi disztribúciók egyre inkább tért nyernek vállalati környezetekben is, ahol nem Józsika PC-je - és annak paraméterei - a mérvadóak. Manapság egy TB nem kerül sokba, még otthoni méretekben sem.

[szerk: megnéztem egy-két számtech bolt kínálatát, a 250G-s SATA disk-ek 20 és 25KHUF között mozognak. Ezekből négy darab 80 és 100KHUF között van. Lássuk be, ahol 1T tárkapacitásra van szükség, ennek duplája se komoly kiadás.]

Hiszen négy darab 250G-s disk épp egy TB-t ad (jó, nem pont annyit, akkor legyen öt és az még több is lesz), a mai alaplapokon ennél több disk csatolására van lehetőség. (persze itt se a low-end alaplapokra gondolok)

Persze a fentiek olvasásánál se a magyar minimálbérből élők lehetőségeiből kell kiindulni, de fel kéne ismerni, hogy ezek nem szempontok a kernel fejlesztésénél.

Ave, Saabi.

kicsit off, de a 90-es évek után y2k előtt volt egy ismerősöm, aki még azt is el tudta adni egy ügyfelének, hogy a falban lévő kábeleket tesztelte 2000 év kompatibilitásra. LOL!

Egyébként igaz amit írsz, van amikor alap az 1TB (vagy nagyobb) és onnan csak felfele megy a kapactiás. Ez főleg akkor jó, mikor készíted az ilyen rendszerekhez a full(!) napi (!) backupot tároló rendszert, 1 hetes rotálással, disk alapon és nem autochangeres, robotkaros mentőegységgel. Na, ott hasznos tud lenni, ha linuxot szeretnél használni ilyen feladatra.

( szotsaki | 2006. 10. 13., p – 20:09 )

Az ext3 maximálisan 8 terabyte volume méretet támogat, ami nem valami sok.

Úgy érzem, engem múltkor a boltban kicsit félrevezettek. Még hogy a 250 GB sok! Na, asszem, holnap lesz egy kellemetlenkedő ügyfelük :D

( nevergone v | 2006. 10. 13., p – 20:11 )

Valamit tudhatunk arról, hogy az új extent tulajdonság mennyire teszi hatékonyabbá a fájlrendszert? Én eddig úgy tudtam, hogy az ext3 amúgy sem különösebben töredezik, erre a cikkben nekem az jön le, hogy azért mégis, csak éppen defragment program nincs hozzá. Vagyis, hogy éppen folyamatosan defragmentálja magát, több-kevesebb sikerrel.
Egy másik kérdés, hogy esetleges fájlrendszer-korrupció esetén nem lehetséges lesz -e valamilyen módon ext3 -ra visszakonvertálni?

Gratulálok a fejlesztéshez, remélem sikeres fájlrendszer lesz.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven