Btrfs v0.10

Fájlrendszer, NAS, storage

Az Oracle alkalmazásában álló Chris Mason - korábbi ReiserFS fejlesztő - ma bejelentette a btrfs névre hallgató, általános célú, GPL lincencű filerendszer 0.10-es verzióját. A következő generációs FS jelenleg prealpha állapotban van, a lemezformátuma jelenleg még nem végleges, éles rendszerre nem ajánlott. Újdonságok:

  • online átméretezés (filerendszer zsugorítás is)
  • helyben konvertálás ext3-ről btrfs-re
  • data=ordered támogatás
  • mount paraméter, amellyel le lehet tiltani a CoW-ot (Copy on Write) és a checksumming támogatást
  • "barrier" támogatás a SATA és IDE lemezekhez

Egy korábbi összefoglaló a btrfs jelenlegi és jövőben tervezett szolgáltatásairól itt.

A bejelentés itt.

( goodbyte v | 2008. 01. 15., k – 23:19 )

Most komolyan, nem a flame miatt, de minek ennyi új FS?
Komolyan mondom már megszámolni se tudnám hirtelen hány van...
Tudom... így van miből választani, de most már olyan sok van, hogy az már szinte zavaró.
Meg aztán inkább 3-4-et csinálnának meg rendesen, nem az hogy mindenki belefog egy tök új dologba, ami talán sose lesz végleges, STABLE.

Teljesen vicces itt ilyen hozzaszolast olvasni. :)

Valoszinuleg azert, mert nem mindenkinek felel meg a reiser bugossaga, az ext3 taknyoltsaga, valamint az, hogy az XFS/JFS vallalati gondozasu. Valamint ha jol emlekszem, ebben az fs-ben lenne par olyan dolog ami eleg kellemes feature-t jelent, es nincs jelen a tobbi valtozatban.

---
pontscho / fresh!mindworkz

Gondolom, a BTRfs után majd egyszer csak kijön a jobb mobilitású BMPfs, azután a védettebb T72fs, a kissé korszerűbb T90fs, de ha valakinek ez nem nyeri el a tetszését, akkor választhatja a LEO2A5fs-t is :)
Amúgy egyetértek, egy fs pont olyan rossz, mint nyolcvan, amiből pénzdobálással választasz, mert nem tudhatod, hogy _ténylegesen_ mit is tudnak. De hát Istenem, ez a nyílt forrású fejlesztések velejárója, nézz csak meg bármi OSS projektet, egyet nem tudsz mondani, amelyiknek legalább valamely fázisa készre lenne csiszolva, de már a pénzes világban is kiveszett a rendes munkára való törekvés. Sic transit gloria mundi...

Tanulni sosem szégyen, úgyhogy állok is sorba felhomályosításért :) !

Legjobb tudomásom szerint az 'oss' az 'open source software', azaz nyílt forrású szoftver fogalmát jelenti, annak a specifikus fejlesztési metodikájával egyetemben (ld. katedrális és bazár), melynek egyik jellemzője, hogy nincs központosított feladatkiosztás, hanem az önkéntes fejlesztők a saját szájuk íze szerinti problémákkal foglalkoznak, azt szintén a nekik tetsző módon oldják meg, aztán a projekt gazdája ezen javításokat vagy beleveszi a kódba, vagy visszadobja.
Természetesen van tudomásom pénzes alapon és céges környezetben fejlesztett oss projektekről is, viszont tagadhatatlan, hogy ezek száma eltörpül a fent leírt össznépi fejlesztéseké mellett.

Nomármost, az is elég jellemző, hogy pl. egy pár kisebb leak mellett alapvetően működő, közösen fejlesztett programban ezen leakeket levadászni sokkal kevésbé hálás feladat, mint pl. új ötleteket, megoldásokat belefejleszteni, olyannyira, hogy én még olyan emberrel nem találkoztam, aki úri passzióból elkezdett volna más után csikket szedni a kódban.
Hasonló a helyzet a több aszinkron dolog együttállásakor bekövetkező ún. Heisenbugokkal is, megfejelve azzal, hogy ezeket már reprodukálni ill. ellenőrizni is külön felér egy farfekvéses sünnek a világra hozatalával.

Figyelembe véve a fentieket, egy (mazochistamentes) közösség által fejlesztett projekt előbb-utóbb a használhatatlanságig/karbantarthatatlanságig veszít a stabilitásából már csak a fent leírt okokból is. Rendszerint ekkor indul új projekt '-ng' utótaggal vagy növekszik a főverziószám a kódbázis teljes újraírása miatt, jelentve némi haladékot az entrópia növekedésének folyamatában...

Külön hab a tortán az önkéntes közösségi fejlesztések koordinálásakor a tervezési döntéshozatal keresztülvitele, ugyanis amíg még semmi sincs kőbe vésve, addig ahány fejlesztő van, annyiféle koncepciót lát helyesnek, értelemszerűen a szuboptimálistól a 'bullshit'-ig terjedő skálára helyezve a többiek meglátását. Na ebből vitatkozáson és sértődésen kívül mást várni fölösleges, ui. nincs lehetőség tekintély-elven felülbírálni az egyéni véleményeket ('így lesz, mert én vagyok a főnök').
Ezért aztán a működő oss projektek nagy részére jellemző, hogy az első verzió a közösség elé úgy kerül, hogy a projektgazda már nagyjából leimplementálta, meghatározva annak a felépítését, így a többiek már egy kész vázra építgethetik a saját kódjukat. Ennek viszont az a veszélye, hogy maga a tervezés egy emberen múlott, így be van korlátozva annak az előrelátó képessége által.

Szóval a fentiek okán érzem az oss fejlesztéseket különösen hajlamosnak a nem kritikus hibák kritikus szintre való halmozására, valamint a kezdeti koncepció kiforratlanságára, és ezen két okból az általános instabilitásra.

Nos, jól látom-e tehát 'az oss fogalmát', és ha nem, akkor miben tévedek?

Ui.: persze ha itt oss alatt "Ofte Stillede Spørgsmål"-t értünk, ami dánul FAQ-t jelent, akkor vissza az egész :)...

Huhh... Az oss-ben (nem a danban) egy kicsit en is benne vagyok, es kapasbol vissza tudom utasitani azt, hogy "egyet nem tudsz mondani, amelyiknek legalább valamely fázisa készre lenne csiszolva". A clapf spamszuroben pl. az SMTP/LMTP resz nekem eleg stabilnak (="kesznek") tunik.

Az oss fejlesztesi modelljen el lehet toprengeni, hogy valoban hatekony-e, van-e az a kritikus tomeg (line of code vagy fejlesztok szama, szemelyi osszeferhetetlenseg, nagy arc, stb.) ami folott kezelhetetlenne valik a dolog - en ugy hiszem van (de ez ugyanugy igaz a kereskedelmi termekekre, nem oss specialitas, ld. mondjuk egy x termek gui-janak megtervezese).

Amit leirtal, az sok esetben igaz, pl. tenyleg, kinek van kedve mas kodjat fixalni? Nekem biztos nem lenne hozza kedvem. A fentebb hivatkozott app-ot egyedul fejlesztem, kb. 3 eset jut eszembe, amikor diff-et kaptam (megneztem, igazuk/jo volt, beepitettem). Ok, ez egy kis projekt, igy aligha gond az, hogy egyszemelyi autoritassal (ha jobban tetszik: zsarnoksaggal) dontom el, hogy merre megy a fejlesztes. Teljesen eletszeru az, hogy 2 fejleszto csoport nem bir zoldagra vergodni, es fork()-olnak, pl. xfree86 es x.org vagy a compiz vs. beril (bar ok nem regen ossze|vissza- egyesultek). Bar azert megkerdeznem halkan, hogy az teljesen eletszerutlen, hogy egy nagy szoftverfejleszto haz 2 fofejlesztoje furja a masikat, mert o egy masik iranyba menne? Csak ott a fonok eldonti a vitat.

Az is igaz, hogy egy csomo oss projekt elhagyott vagy elhanyagolt. Olvastam egy irast, ami szerint a sourceforge az abandonware-ek tarhaza, es a projektek 99%-at elhagytak a fejlesztoik. Ebben is lehet valami.

Azt sem vitatom, hogy sok esetben a projektgazda mar lekodolta a vazt, es 2 szem kevesebbet lat, mint 10 vagy 20. En pl. gondolkodom egy ideje, hogy a program fork()-olas helyett valtson thread-ek hasznalatara, ami elegge alapveto valtoztatas (lenne vagy lesz), de ez csak mondvacsinalt problema, sokkal inkabb hozzaallas kerdese. Ha a szalak hasznalata jobb, mint a fork-e, akkor elegge tarthatatlan az a hozzaallas, hogy "dehat az a resz mar keszen van...".

Szoval ugy hiszem, nem oss vs. zart kod, sokkal inkabb szemelyiseg fuggo a leirt problemak nagy resze.

ASK Me No Questions, I'll Tell You No Lies

Végülis igen, igazságod vagyon, tényleg nem oss-specifikus, csak zárt forrásnál esetleg nem látszik a háttérben lévő katyvasz.
Kissé utánagondolva rájöttem, hogy igazából én vagyok túlzottan reakciós őskövület, mert még mindig abban az internet előtti sémában gondolkozok, amikor egy kiadott programot elküldtek sokszorosítani kazettára/floppyra/cdre N+2 ezer/millió példányban, kiszállítottak a világ minden részére, és ha kiderült, hogy pl. a menü keretére kattintva szétszáll a progi, akkor nem az volt a válasz, hogy "'Oops I did it again', frissíts az 1.0.2.4.rc7-re", hanem a kiadó cég/ember akkora arcot veszített, hogy tőlük már senki sem vett semmit komolyan. Azok a régi szép idők :) ...

hanem a kiadó cég/ember akkora arcot veszített, hogy tőlük már senki sem vett semmit komolyan.

Ez az elmelet, a gyakorlat meg az, hogy vegyuk pl. a vindoze x.x-t, ami dobott egy kek kepernyot. Erre azert ra lehet mondani, hogy "szetszallt", es megis, a vindoze eladasok szama nem csokkent. Ott van az exploder/outlook paros, amire biztonsagi ceg meg sose mondta, hogy "na igen, igy kell egy brozernek mukodni" (azt viszont igen, hogy magas biztonsagi kockazatot jelentenek). Es megis, ezt hasznaljak a legtobben.

Szoval egy dolog az, hogy teljesen logikus, amit irtal, az meg egy masik dolog, hogy a vilag nem igy mukodik (mert az emberek nem logikusak). Egyebkent (ma, az Internet koraban) en tulzasnak tartom a "ha szetszall, akkor sose veszek toled semmit", sokkal fontosabb a hibak es az ugyfelek megfelelo kezelese. Ha fixalod a hibat (nem csak duma, hanem felteszed a kezed, hogy fault-oltal && kijavitod a hibat), es simogatod kozben az ugyfelet, akkor imho rendben vagyunk. En legalabbis igy tennek: megkoszonom a bug report-ot, elismerem a hibat, es kijavitom azt, majd hirlevel:
"frissitsetek az 1.0.2.4.rc7-re". Es mindez oss.

ASK Me No Questions, I'll Tell You No Lies

Csak azért ne mossuk össze a 'mindent megtettem, mégis maradt benne hiba, itt a javítása' hozzáállást a 'na és, legfeljebb ha valaki fog benne valamit, majd adunk ki új verziót'-tal.
Kedvenc és elég egyszerűen kivitelezhető próbám erre, hogy fogom az adott programot, egyszer elindítom valgrind alatt és végigjárom az általam használt funkcióit amennyire csak tudom. Aztán megnézem a logokat, majd felteszem a kérdést, hogy a t. fejlesztőgárdából ezt miért nem csinálta meg senki? "Ingyen van, ne panaszkodjak?" - végül is, rendben, de attól még igénytelenség.
Félreértés ne essék, nem várom el a tökéletes hibamentességet, de az arra való törekvést viszont igen!
Persze elég szennyes része a munkának egy nagyobb program esetén pl. végiggondolni minden egyes dinamikusan foglalt objektum életútját (mikor ki hozza létre, mikor mi történhet vele, mikor ki szabadítja fel), de ez is része a dolognak, amit illenék nem elsumákolni, hogy 'majd a gc eldobja, ha nincs rá ref'. Persze, az esetek nagy részében igen, aztán vagy mégis maradt valahol egy, vagy nem. Meg hát ugye kevés rosszabb dolog van annál, amikor a java programozó c-ben próbál dolgozni...
Hasonlóképpen nem általános szokás lekezelni az összes hibalehetőséget, mert 'minek nyűglődjek vele, ha millióból egyszer jön be' - és akinél pont előjön, az I.J... Hasonlóképpen a 'minek gondoljam végig, beolvasom egy GList-be oszt jóvan' - és lehet, hogy 1 kbyte ram elég lenne neki, így meg eszik 2 gigát.

Száz szónak is egy a vége: ahogy nézem, a szaktársak jó része már csak lustaságból is hajlamos a munka kevésbé dicső részét kihagyni/összecsapni, és ha nincs olyan kényszerítő erő, mint pl. 'az ügyfél fizetett érte' ill. 'köv. verzió csak jövőre mehet ki, addig ennek meg kell állnia a lábán', akkor ki is hagyja/össze is csapja. És mindez szinten oss.

Szerk.: Megint végigolvasva rájöttem, hogy sajna napjainkban a pénzes és ritkán frissíthető dolgokat sem rakják össze rendesen, azaz inkább a "sz@rt ki nem adok, a nevem sem adom hozzá"-mentalitás hiányzik sok esetben. Azt viszont fenntartom, hogy nevesített fejlesztésnél ennek legalább a lehetősége megvan, a nagyobb, sok ember által fejlesztett oss-nél viszont még az sem.

Minek? Mert tobb kozul lehet valasztani, ez a szabadsag lenyege, a valasztas lehetosege. Az ido ugyis eldonti, hogy mi/mik maradnak fenn hosszu tavon is, barmilyen "szep" is volt a kezdet. Most miert faj az, ha valaki probalkozik? Hadd tegye, meg a vegen valami jo is kisulhet belole, ha meg nem, legalabb otleteket adott masoknak, vagy tudomisen :)

( doc | 2008. 01. 16., sze – 08:36 )

régebben mindenki saját Linux disztrót csinált, most (a hozzáértőbbek) új FS-t
pár év és elmúlik, aztán jön egy újabb divat
mindazonáltal egy jól működő, gyors, sok okossággal felvértezett FS jó lenne, de ha nincs mögötte kellő támogatás, akkor bukta... a reiser is jól indult, mégsem lett belőle az, ami lehetett volna...

A ReiserFS aktív fejlesztését befejezték, karbantartási üzemmódra váltott. Ez azt jelenti, hogy a bugokat kijavítják, de új feature nem lesz hozzá. Az ok, amiért a ReiserFS-t nem fejlesztik tovább, hogy közben elkészült a Reiser4, a következő generációs Reiser-féle filerendszer. Ez azonban nem került be a mainline kernelbe, mert voltak olyan kritikák, hogy a beolvasztásához alapvető infrastruktúrákat kellene felforgatni. A végén már majdnem beolvasztásra került, de ekkor került be Reiser a börtönbe, így nem volt, aki nyomja a dolgot. A Namesys-t - a Reiser* filerendszerek mögött álló céget - Reiser árulja, mert abból fedezné a jogi költségeket. A megmaradt fejlesztők irányítás hijján vegetálnak. Itt tartunk most. A btrfs viszont jó választás lehet azoknak, akik a ReiserFS-ről szeretnének majd váltani egy aktívan támogatott filerendszerre. A btrfs-ből kb. egy év múlva lehet olyan FS, ami már tesztelhető. Akkora készül el pl. az online fsck és egyéb betervezett szolgáltatások.

--
trey @ gépház

Azt hallottam, hogy Hans Reiser Chris Mason nevét is megemlítette a gyilkossági ügy kapcsán, így most ő is börtönben van.
Eddig nem tudtam, hogy miért gyanús nekem ez a két pasas, de most, hogy elindult a Free Mason! akció az amerikai rendszámiparban, már tudom miért...

http://www.plateshack.com/y2k/Ohio/oh2003freemason.jpg
http://www.dorkinglabs.com/images/freemason.jpg
http://www.plateshack.com/y2k/Washington2/wa2005freemason.jpg

( ProTech | 2008. 01. 16., sze – 16:21 )

Egyebkent meg anno az ext4 fejlesztese kapcsan szedtek ossze, hogy azert kellenek az uj filerendszerek mivel megvaltozott a hardware, es a jelenlegi filerendszerek nem tudjak hatekonyan kezelni a mostani nagy tarolokat.

A Winchesterek sebessege nagyon lassan novekszik, viszont a tarolokapacitas igen gyorsan. Az, hogy 1 oraig menjen egy fsck indulaskor pedig nem megoldas. Ezert uj filerendszerre van szukseg ami alkalmazkodik az uj kovetelmenyekhez. Ezt a filerendszert nem ismerem, de szukseg van innovaciora.