Hamarosan megkezdődhet az ext4 filerendszer fejlesztése

Címkék

Theodore Ts'o - (többek közt) ext2/ext3 filerendszer fejlesztő - egy javaslatot és tervet postázott a Linux kernel levelezési listára, amelyben az ext3 filerendszer továbbfejlesztéséről, és az ext4 filerendszer létrehozásáról olvashatunk.
Ted azt írta, hogy az elmúlt hetek beszélgetéseiben kiderült, hogy az ext3 továbbfejlesztésben több ember is érdekelt lenne. Nem meglepő ez annak fényében, hogy az ext3 a legnépszerűbb és leggyakrabban használt filerendszer. Kedvelt a kernelfejlesztők körében is, így az érdeklődés nagyobb, mint más filerendszerek esetén.

Az ext3 továbbfejlesztésének felvetésekor az legtöbbször az alábbi aggodalmak merültek fel: stabilitás, kompatibilitás, kód komplexitás. Sajnos ezeket az aggályokat néha együttesen, keverve vetették fel a fejlesztők, ezért nehéz volt előrehaladni a probléma megoldása felé.

Most úgy tűnik, hogy megtalálhatják a megoldást. A javaslat a továbbfejlesztésre:

Ted egy négy pontból álló listán szedte össze azokat a lépéseket, amelyek az ext4 megszületéséhez vezethetnek.

  • Első lépésként létrehoznának egy új filerendszer-kódbázist a 2.6-os kernelfában a
    /usr/src/linux/fs/ext4 alatt. Ez az fs eleinte "ext3dev" filerendszerként regisztrálná magát. Természetesen ez határozottan CONFIG_EXPERIMENTAL filerendszer lenne, azaz jeleznék, hogy nem végfelhasználóknak való kód, hanem az ext3 fejlesztői fork-ja.
    Hasonló kódelágazás jönne létre a fs/jbd kapcsán is. Cél: a 64 bites jdb elérése, amelyet majd az fs/ext4 és egyéb más filerendszerek (pl. az ocfs2 későbbi verziói) fognak használni.
  • Az ext3 filerendszer kódjába csak bugfixek, kódtisztítások, oops és biztonsági fixek kerülnének. Az összes fejlesztés kizárólag az fs/ext4-be menne. Az még kérdéses, hogy az kis rizikóval járó fejlesztéseket beletegyék-e majd az ext3-ba is, vagy azokat csak az ext4 felhasználók élvezhessék.
  • Az ext4-nek továbbra is visszafele kompatibilisnek kell lennie, azaz mountolni kell tudnia az ext3 filerendszert. Erre elsősorban azért van szükség, hogy a későbbi upgrade-ek ext3-ról ext4-re simán menjenek.
  • Ha minden rendben megy, és a fejlesztők elégedettek az fs/ext4-be bekerült változtatásokkal, és egyben bíznak az új fs stabilitásában, akkor a fejlesztés egy pontján - valószínűleg 6-9 hónapon belül - nyomnak egy patch-et, amelynek nyomán az "ext3dev" fs "ext4"-ként regisztrálja magát. Ezután még kell "egy kis idő" amíg a fejlesztők kijelenthetik, hogy az új fs olyan stabil, mint az ext3 napjainkban. Ez talán 12-18 hónap múlva következhet be, amikoris a fejlesztők kérni fogják az fs/ext3/*.c kód törlését, és az ext4 teljesen átveheti az ext3 szerepét.

Bővebben Ted levelében itt.

Hozzászólások

Nem értem, hogy ez most miben lesz jobb. 64 bit? az smafu, ha bitekre megyünk, akkor inkább zfs :)

_szerintem_ nem sokban, elvegre ext2/3 se ter el sokban, ha valami dramai valtozas lenne akkor azt mar kar lenne "ext"-nek hivni, ahogy szo is van rola: valamilyen szintu kompatibilitas fontos, egy nagyon nagy valtoztatas mar kvazi uj filerendszert eredmenyezne az meg van mas is sok, ext3-at pont azert hasznal sok ember mert mar viszonylag kiforrott, jol ismert, es elterjedt. Gondolom az ext4 se fog ezert sokban kulonbozni az ext3-tol, ha jol remlik LKML-en fs max meret meg ilyenekrol van szo (ami extentekkel megoldhato ext3-ban is mondjuk, de lehet kevesbe elegans, meg utana tobbe nem lehet visszamountolni "normal" ext3-kent, meg hasonlok).

Rájöttem közben a megfejtésre:
vannak olyan emberek a Linux környékén, akik felelőtlenségnek érzik, hogy egy stabilnak mondott kernelben próbálkozzanak kódolni, így mivel nincs fejlesztői ág, csinálnak maguknak a kernelben ilyet: ext3 helyett ext3dev néven.
Ez persze már eleve beteg ötlet, de még betegebbnek fog tűnni, ha belegondolunk, hogy mi van akkor, ha a fájlrendszer fejlesztése közben olyan utakat is érinteni kell, amelyeket más is használ, ergo ismét csak ott tartunk, hogy a stabil kernelen megy a kísérletezgetés. :)

Szerintem meg epphogy ez a jo! Vagy az jobb lenne, ha a ext3-at kezdenek el szetzuzni? Pont azert csinalnak bele kulon fs-t (ext3dev neven) es jelolik experimental-nak, hogy ez ne okozzon gondot. Azt, hogy mast is erint, es abbol baj lehet, azt meg kevesbe hinnem, elvegre a reiser4-el is pont az a baj, hogy tul sok mast erintene, azert nem olvasztottak meg mindig be (tobbek kozott). Szerintem ez a magatartas ponthogy jo jel arra nezve, hogy azert nem akarnak minden szetkefelni stable szeriaban.

Aha, es melyik disztribben jott ki ez a kernel frissites? :) Mert ugye elvileg azt "illene" hasznalni. Nem veletlen hogy a stable disztribek sem szoktak azonnal ugrani az uj kernelekre. Az end-usereknek (mi) elvileg azt kellene hasznalni, aki kernelt _akar_ fejleszteni es debugolni, tesztelni, stb az hasznalja az uccsot :) Na ez volt a flame, a komoly resze pedig annyi, hogy ebben van valami, hogy fura ez a stable/devel elosztas ilyen szintu eltunese, de allitolag ugyanilyen gaz volt amikor kulon volt: a devel kernel olyan szinten eltavolodott a stable-tol, hogy az uj stable ad "stabilizalasa" eleg sok idot felemesztett ... Az az igazsag hogy ez kevesbe technikai mint fejlesztes menedzselesi problema mar, ezert nem erzem magam KOMPONENSNEK (mielott valaki leszol, direkt irtam igy, ugye klasszikus, bar volt hogy valaki kijavitott hogy rosszul irtam ...) a temban, tehat en eldonteni nem tudom, nyilvan, max csak a velemenyemet irhatom le ...

mindazonaltal nem is olyan regen a stabil (x86) nvidia driver a stabil kernellel olyan szepen nem mukodik egyutt gentoo alatt, hogy orom volt nezni. a downgradelt kernellel nem ment az alsa, ugyhogy kenytelen voltam ~x86 nvidia drivert beengedni.

Itt meg a fejlesztok egymasramutogatasa miatt nem volt egyhamar (par napja meg nem volt, ekkor neztem utoljara) megoldas. Szoval ekkora kavarnal mar a nagyobb disztrokeszitok munkajat is alaposan megnehezitik, es ezt mar a az egyszeru juzer (aki nem linux guru, csak egy egyszeru gentoo felhasznalo) is eszleli.

Azert azt jo tudni, hogy gentoo alatt az nvidia x86 stable verzioja a 6629,ami azert mar eleg regi.Nem is csodakszom hogy nem ment. Amd64-en mar a 8756,amivel viszont kell mukodnie.
Majd akkor lesznek jo dolgok,ha a 7.1-es Xorg lesz a stable(ami hamarosan varhato),mert azt nem tamogatja az nvidia.:))

http://nsuperbus.blogspot.com

Lekopogom: nekem se volt :) Se server, se desktop kornyezetben. Viszont nem is szokasom mar egy ideje a legutolso eppen-hogy-kijott kernelt feltenni, ha a diszrtributor feladata ugye szamomra a megfelelo stabil kernel biztositasa. Na az mas kerdes, hogy pl van egy gepem amin jatszok ilyenekkel, neha meg sajat kernel modositasokkal is kisereletezem, _de_ akkor en tisztaban vagyok ott a kovetkezmenyeivel ... Aztan lehet, csak szerencsem volt ;) Nameg ahogy latom az utobbi 1-2 evben divatta valt szidni a Linuxot, az meg a masik. Mindegy, ezek engem annyira mar nem zavarnak, amig nekem arra jo amire. Amire meg nem, arra meg jo mas OS, van nalunk is rengeteg Solaris, sot meg akar FreeBSD es OpenBSD is pl. Nem (ez) a problema ...

"Viszont nem is szokasom mar egy ideje a legutolso eppen-hogy-kijott kernelt feltenni, ha a diszrtributor feladata ugye szamomra a megfelelo stabil kernel biztositasa. Na az mas kerdes, hogy pl van egy gepem amin jatszok ilyenekkel, neha meg sajat kernel modositasokkal is kisereletezem, _de_ akkor en tisztaban vagyok ott a kovetkezmenyeivel ..."

Nekem szokásom (újabban megint), mégsincs (több) bajom (mint más operációs rendszerek alatt, pedig nyúzok egy-kettőt).

--
trey @ gépház

Az ext4-nek továbbra is visszafele kompatibilisnek kell lennie...
ez a halálom... :)

miért?

szvsz nagyon sok kompromisszummal jár az, h valamit visszafelé kompatibilissá akarnak tenni, és ezek a kompromisszumok általában csak a innovatív ötleteket gátolják.

Miért nem lehet azt mondani, hogy kész, itt a vége, ha ez kell, formázd meg a winyot...? :)

Olyan is...

Mondjuk egy szavam sem lehet, működni működik, csak nem használhatok ékezetes fileneveket, illetve csak onnan veszem észre, hogy egy fsck esedékes lenne, hogy crc errorosak a letöltéseim...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az. Sajnos csak freeware, és nem OS...

Ez viszont GPL: http://ext2fsd.sourceforge.net/#ext2fsd
Először ezt próbáltam, működött is, és azt állítja magától, hogy kezeli a különböző karakterkódolásokat, de nekem nem sikerült rábírnom, mint ahogy az automountra sem. Le va írva, hogy hogy kell, csak nálam nem működött...

Van még ugye a Paragorn Ext2fs, de az se ismeri a journalingot, (bár az ékezetes fileneveket állítólag igen) így gondoltam felesleges lenne "megvenni".

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

pl. most is fel tudsz régi rendszeren mountolni ext3 mat ext 2 ként csak a journal feature nincs.
tudom, bastya_elvtars-nak is írom, hogy ok, persze h vannak előnyei.

Úgy általánosságban van egy teoriám a műszaki fejlesztések terén a visszafelé-kompatibilitásról. Előbb utóbb rájövünk, hogy mégse kellett volna. Ez a teoria a számtech területen nem igazán állja meg a helyét, mivel elég nagy a pörgés, de azért itt is vannak olyan dolgok.

Pl: mono vs sztereo adás. Mikor kitalálták, kritérium volt, hogy az addig megvásárolt vevők képesek legyenek az új technológiára, és az addig felépített adókkal sugárzott adásokat hallgatni lehessen az új vevőkkel. Sokan (mármint relatíve sokan :)) ennek tudták be a quadrofon adás "elmaradását" (közben jött a DAB)
Vagy fekete-fehér tv - színes tv...

ehh, na mindegy, messze mentem, bocs.

lgb írta, hogy ha generális változások is lesznek, akkor má' ne 'ext' legyen a neve. Egyébként meg minek? :)

Pl: mono vs sztereo adás. Mikor kitalálták, kritérium volt, hogy az addig megvásárolt vevők képesek legyenek az új technológiára, és az addig felépített adókkal sugárzott adásokat hallgatni lehessen az új vevőkkel. Sokan (mármint relatíve sokan :)) ennek tudták be a quadrofon adás "elmaradását" (közben jött a DAB)
Vagy fekete-fehér tv - színes tv...

Jah, és pont a kompatibilitás miatt küzdünk a TFT monitorokon az interlace-elt videostream-ekkel :D

> szvsz nagyon sok kompromisszummal jár az, h valamit visszafelé kompatibilissá akarnak tenni, és ezek a kompromisszumok általában csak a innovatív ötleteket gátolják.

Zene füleimnek :-) Örülök hogy nem csak én gondolom így. Szerintem az innovatív ötletek gátolása mellett van még egy hatalmas hátrányuk: baromi értékes fejlesztői erőforrásokat kötnek le relative hülyeségre, ahelyett hogy sokkal értelmesebb dologra fordítanák.

Egyébként az értelmetlen és/vagy szar szabványokról is ugyanez a véleményem: baromira gátolják az innovációt. Például LSB, amit nem kitaláltak úgy hogy jó legyen, hanem gyakorlatilag kőbe vésték és szentírásnak próbálják meg tekinteni azt ami 30 évnyi (sokszor koncepció nélküli) toldozás-foltozás során keletkezett.

Viszont szükség van ilyen kőbe vésett dolgokra, ha legalább a feltételeket akarjuk megteremteni arra, hogy végre megjelenjenek komolyabb kereskedelmi software-ek Linuxra. De nem is ezzel van bajod, írtad... Gondolom azért nem találtak ki egy teljesen új dolgot mert így könnyebb rávenni a distribeket a betartására.

--
sirkalmi

szabvanyokra ott van igazan szukseg, amit mindegy hogyan csinal az ember, de gond van ha mindenki mashogy csinalja.
pl:
tok mindegy, hogy az ut jobb, vagy baloldalan kozlekedsz az a lenyeg, hogy mindenki ugyanugy csinalja.

a szabvanyok jok, es hasznosak, csak a maguk helyen.
Anr - http://andrej.initon.hu

Valaki tud már konkrét feature listát, hogy mit terveznek bele a max méret növelésén kívül, mert lehetne kicsit fejleszteni a hibatűrését.

(Tudom, tudom, ext3 stabil, mint a beton, sajnos nálunk nem volt az. Az még oké, hogy a drága jó áramszolgáltatónk időnként kirántotta a gép alol a netet, emiatt FAT32 effekteket produkált, de hogy UPS beszerzése után normál, igaz folyamatos működés mellett magátol szétesett az egész, az "kicsit" furcsa volt. Nem flamewart szeretnék elindítani, de megbízhatóságban a ReiserFS és (win-n) az NTFS nálunk jobban muzsikált, mint az ext3. Ha másnak nem, örüljön.)