Készül a btrfs a mainline kernelbe

Fájlrendszer, NAS, storage

A Chris Mason és társai által csendben fejlesztett következő generációs Linux filerendszer, a btrfs kezd végleges alakot ölteni (lemezformátum tekintetében). A 2007. júniusában bejelentett filerendszer majd' másfél évnyi aktív fejlesztés után lassan bekerülhet a mainline kernelbe és elérheti az 1.0-s állapotot.

Chris még szeptember végén jelentette be, hogy migrálta a btrfs forrásfáját git tárolókba (kernel modul, progs).

Akkor voltak a kóddal problémák, de Chris úgy látta, hogy a nagyon aktív fejlesztés alatt álló filerendszer fejlesztése szempontjából ezen a ponton az lenne az ideális, ha bekerülne a mainline kernelbe és ott folytathatnák a vele kapcsolatos munkákat.

Chris terve az, hogy a btrfs lemezformátumát az év végéig véglegessé tegyék.

Pár nappal ezelőtt Chris bejelentette, hogy frissítette a git (forrás)fákat a 2.6.28-rc5-ös kernelhez és tesztelte a linux-next kernelfával, amely a belépőt jelenti a mainline kernelbe.

A btrfs 1.0-s roadmap-je szerint a fejlesztők nem állnak rosszul ahhoz (1 darab "folyamatban levő"), hogy elérjék az 1.0-s állapotra betervezett feature mérföldkövet.

( zdesigner | 2008. 11. 30., v – 11:27 )

"Akkor voltak a kóddal problémák"
Erről most valamiért a Reiser4 ugrott be, amit a világ minden kincséért sem akartak a mainline kernel közelébe engedni, bezzeg a btrfs... :P

A két dolog teljesen más. A tiltakozóknak a Reiser4-gyel dizájn problémái voltak (azaz a fejlesztése előrehaladtával sem lett volna számukra megfelelő, bármit is csináltak volna vele a fejlesztői), a btrfs dizájnja ellen - ahogy tudom - nincs kifogás, sőt a Linux kernel új, fő filerendszereként beszélnek róla, amihez az ext4 lesz a belépő. A btrfs-sel az akkori fejlesztési (fejletlenségi) szintjéből adódóan voltak problémák: bugokat ki kellett javítani, hiányzó feature-öket kellett még implementálni. Szóval más tészta.

--
trey @ gépház

Az ext4-hez képest nagyobb file- és volumeméret támogatás. Ezen kívül (az ext4-et nem ismerem, így nem tudom abban mi van, de) a btrfs tud(ni fog):

  • adat és metaadat checksum-olást több algoritmussal
  • írható snapshot-okat
  • kisméretű file-ok helyhatékony tárolását
  • tömörítést
  • objektum-szintű tükrözést és csíkozást (stripe)
  • integrált "multiple device" támogatást több RAID algoritmussal
  • subvolume-okat
  • online filerendszer-ellenőrzést
  • nagyon gyors offline filerendszer-ellenőrzést
  • hatékony inkrementális backup-ot és FS mirroring-ot
  • online filerendszer töredezettségmentesítést

Majd valaki melléteszi az ext4-et.

--
trey @ gépház

van arról valami hír, hogy ezek a snapshotok hogyan lesznek elérhetőek? a Linux jelenlegi fájlrendszer-struktúrájába számomra nemtriviális ezeknek az implementálása. Mount opcióként kéne megadni mondjuk a dátumo, vagy hogy-é? Felteszem az OSX-féle Time Machine, mint implementáció nemigen játszik egyelőre:D 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Microsoft: Lemasolja, ad neki valami uj nevet, es utanna ugy allitja be a dolgot, hogy a legjobb sajat talalmany.

Ezek kozul az elso nem zavar.
Masodik miatt egy ujabb stringet kell megjegyezni ez zavar.
Harmadiknal neha nem tudom, hogy sirjak vagy nevessek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az adat checksumolás mit jelent a gyakorlatban?

Mondjuk van egy kernel, vagy hardver hibám, és a lemezre más kerül, mint aminek kellett volna, és ezt észreveszi? (Szóval mint egy verify?)

Tömörítés olyasmi, mint NTFS-ben, hogy azt mondom, hogy az adott könyvtár alatti dolgok legyenek tömörítve (pl. mailbox, vagy /var/log), és akkor transzparensen és gyorsan (pl. lzop) ami belekerül, tömörített lesz, amit kiolvasok, az meg kitömörítve látszik?

G

( blackluck v | 2008. 11. 30., v – 18:19 )

Arrol volt esetleg vmi elorejelzes vagy almodozas, h mikorra varhato h btrfs vagy ext4 mar elterjedtebb lesz esetleg mikor lesznek tobbsegi hanyadban?
(csak kivancsisag keppen, h szerintuk mikorra lesz kelloen stabil es hasznalhato, mert az egy dolog h elvileg kozel az 1.0-as btrfs meg ext4 se dev-kent fog mar szerepelni az ujabb kernelekben)

--
Erezd a rigmust! Erezd a rigmust! S koncentralj a gorkocsira most!

( Dwokfur v | 2008. 12. 01., h – 07:22 )

Nagyon ígéretesnek tűnik ez a fájl rendszer. Nekem a snapshot tetszik a legjobban a képességei közül. Annak idején pozitív tapasztalataim voltak a reiserfs3-mal sebesség terén. Sajnos a tesztrendszeren a dugó-kihúz teszten nem ment át.
Volt még egy zavaró dolog, ami megrémített. Kis chunk-okat a metaadatokkal tárolt, ami gyorsított rajta. Ugyanakkor belefutottam abba, hogy egy grub floppy-t készítettem és fájlokat dd-ztem rá. Nem lett jó. Nem értettem miért. És kiderült, hogy ezért. Volt valami mount opció, hogy ki lehessen ezt kapcsolni. Asszem nochunk. Utána működött a floppy, de csak azután, hogy a fájlokat valahol újonnan létrehoztam.
Hogy működik ez a btrfs-nél? Van ilyen betesége? Van olyan mount opció, ami kikapcsolja? Csinált már valaki ilyesmit?
(lusta on)
Esetleg valaki megnézné nekem, hogyha dd-zik egy fájlt és visszamásolás utána rányomat egy diff-et, akkor van-e különbség? (lusta off)

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Nagyon ígéretesnek tűnik ez a fájl rendszer."

Jaham. Alig várom, hogy véglegessé váljon a lemezformátum, hogy lecserélhessem a jó öreg ReiserFS-t. A bejelentés óta kísérem figyelemmel és tesztelem. Jelenleg egy 80GB-os HDD-n van "unstable" btrfs, amire rsync-elem a ~ könyvtáramat folyamatosan. Eddig problémát nem láttam vele.

"Annak idején pozitív tapasztalataim voltak a reiserfs3-mal sebesség terén."

Nekem semmi bajom sincs a Reiser-rel. Nem is tudom mióta használom. Tán 7-8 éve is van már. Sose volt bajom vele.

"Sajnos a tesztrendszeren a dugó-kihúz teszten nem ment át."

Az én tapasztalataim szerint jól tűri a ReiserFS a szabálytalan leállítást.

"(lusta on)
Esetleg valaki megnézné nekem, hogyha dd-zik egy fájlt és visszamásolás utána rányomat egy diff-et, akkor van-e különbség? (lusta off)"

Ha megmondod pontosan mit szeretnél, megnézem neked.

A "dd-zik egy fájlt" - ezt értem

"és visszamásolás utána" - honnan másolja vissza?

"rányomat egy diff-et" - diff-et? nem valami digest-et (md5, sha1, ...) inkább?

--
trey @ gépház

"Ha megmondod pontosan mit szeretnél, megnézem neked."
Mondjuk egy grub floppy készítést kéne emulálni. 


# cd /usr/lib/grub/i386-pc
# dd if=stage1 of=/dev/fd0 bs=512 count=1
1+0 records in
1+0 records out
# dd if=stage2 of=/dev/fd0 bs=512 seek=1
153+1 records in
153+1 records out

"honnan másolja vissza?"
Mea culpa. Csak az járt a fejemben, hogy egy másik device-ra történik a dd...

"diff-et? nem valami digest-et (md5, sha1, ...) inkább?"
Persze, persze. Igazad van.

Köszi, ha megnézed.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Annak idején pozitív tapasztalataim voltak a reiserfs3-mal sebesség terén. Sajnos a tesztrendszeren a dugó-kihúz teszten nem ment át.

Így tapasztaltam én is. Gyors, de nem annyira megbízható, mint az ext3.
Érdekes módon nem a dugó kihúzásnál rontotta el a fájlokat, hanem a legközelebbi mount során a journal újrajátszásánál. Ha dugókihúzás közben volt valami írás, és legközelebb read-only módban mount-oltam föl a fájlrendszert, akkor ott voltak a félig írt, esetleg 0 bájt hosszú fájlok, de nem volt gubanc. Az első rw mount után azonban megjelentek a félig írt fájlok darabjai más fájlokban is. Persze amíg csak a /var/log/messages kutyulódik össze a /var/log/Xorg.0.log-gal, addig ez nem zavar, vagy észre sem vesszük. De ha "rpm -i ..." közben rántják ki a tápot, abból mindenféle csúnya keveredés tud lenni.