Btrfs: az év végére alkalmas lehet az korai alkalmazók, felhasználók számára

Két éve annak, hogy az Oracle alkalmazásában álló Chris Mason bejelentette, egy új, korszerű képességekkel rendelkező Linux fájlrendszer fejlesztésébe kezdett Btrfs néven. A fejlesztés azóta is folyik, egyre több közreműködő jelenik meg a projekt körül.

Másfél évvel a fejlesztés megkezdése után Chris elérkezettnek látta az időt, hogy kérje a Btrfs kódjának beolvasztását a mainline kernelbe. A beolvasztás 2009 január elején meg is történt. Természetesen azóta is folyik a fejlesztés. Folyik a fájlrendszer stabilizálása és teljesítményének javítása. Ettől függetlenül a Btrfs jelenleg egy erősen fejlesztői fázisban levő, éles felhasználásra nem ajánlott fájlrendszer.

De vajon mikor lesz a Btrfs éles felhasználásra ajánlott, alkalmas?

Nemrégiben a Linux Foundation marketing igazgatója, Amanda McPherson interjút készített Chris-szel. Ebben az interjúban a hölgy feltette a kérdést a fejlesztőnek:

Mi a Btrfs jelenlegi helyzete? Tudom, hogy január 9-én beolvasztásra került a 2.6.29-es kernelbe; mikor lesz kész a felhasználók számára éles felhasználásra?

A Btrfs korai céljainak egyike az volt, hogy felkeltsük olyan cégek és fejlesztők figyelmét, akiket érdekel a projektben való közreműködés. Ez segített felépíteni egy erős hozzájárulói csoportot, és [most] a stabilitásra és a teljesítményre összpontosítunk.

A számunkra ma szükséges Btrfs szolgáltatás legtöbbjének stabilnak kell lennie - beleértve a multi-device támogatás alapjait, a checksumming-ot és snapshotting-ot -, ezek létfontosságúak, mert más Linux fájlrendszerek nem nyújtják ezeket [a szolgáltatásokat] jelenleg. A 2.6.32-es kernelkiadás után azt várom, hogy a dolgok olyan állapotban lesznek, hogy elkezdhetjük toborozni a komolyabb tesztelésre vállalkozó korai befogadókat, felhasználókat (eredeti: "early adopters").

Tehát, talán az év vége felé már várható, hogy a bátrabbak nekikezdhetnek a korai bevezetésnek, befogadásnak. Ebből az alkalomból a The H Open egy összefoglalót készített arról, hogy mit érdemes tudni a Btrfs-ről és annak használatáról (példákon keresztül). A cikk elolvasható itt.

Hozzászólások

Használni eddig (és még most sem nagyon) nem sok értelme lett volna. _Tesztelni_ annál inkább. A cikk arról szól, hogy a nagyon bátrak _várhatóan_ a 2.6.32 megjelenése után elkezdhetnek elgondolkodni azon, hogy elkezdik majd valamire _használni_, de ez is leginkább komolyabb tesztelést jelent. Olyasmire gondolok, hogy valaki rendszeres backup mellett rábízza a /home vagy /var fájlrendszerét, stb, de semmi esetre sem azt, hogy nekiáll megformázni a vállalati storage-ot Btrfs-re.

--
trey @ gépház

Értem, köszönöm a választ.

http://tinyurl.com/mv694h

Angol nyelvre állítottam át, magyarral nem merem belinkelni. :)
--
Those who do not understand Unix are doomed to reinvent it, poorly. -- Henry Spencer, 1987
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Igén, ezeket szoktak nevezni oroszok "teszt hörcsögöknek". :)

Amúgy az orosz "unix", "unix like" közösség egy kicsit mást ért "úttörő" alatt. Olyan embert, aki nem ért valamihez, de ettől függetlenül hittel és lelkesedéssel beleveti magát minden ezzel kapcsolatos témába magyarázni, kritizálni. Általában linux fan boyokról van szó. :)

Lásd alábbi képen megmutatott "úttörő" profizmust, kumisz lótejből való "készítésénél".

http://caricatura.ru/black/korsun/pic/326.jpg
--
Those who do not understand Unix are doomed to reinvent it, poorly. -- Henry Spencer, 1987
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Egy beta teszternek nem feltétlenül kell értenie rendszer alacsony szintű működését (ha ért hozzá, az csak bónusz). Azt kell tudnia, hogy le tudja írni: "ezt csináltam, ez lett az eredménye, itt vannak a logok". Vagy még ennyit sem, mert a rendszerbe épített "telemetria rendszer" automatikusan elküldi a bugjelentést a fejlesztőnek egy központi adatbázisba. Ilyenre van példa szinte mindenhol.

--
trey @ gépház

Nyugalom, lényegében magam is "hörcsög" lennék, csak én hardcore desktop usernek szoktam becézni magam. Igyekszem nem "úttörőként" viselkedni, de ez lehet hogy nem mindig sikerül. :)

Nemsokára szeretném Zenwalkom alatt a /home-ot btrfs-re helyezni. Észérvem, szükségem nincs per pillanat rá, de nagyon hajt a kíváncsiság. :)
--
Those who do not understand Unix are doomed to reinvent it, poorly. -- Henry Spencer, 1987
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Arra leszek kíváncsi, hogy miután az Oracle bekebelezte a Sun-t, mi lesz Chris pozíciója, és mi lesz a btrfs jövője. Merthogy az Oracle nem arról híres, hogy hosszú távon két rendszert párhuzamosan fenntart, és bárhogy nézem, a ZFS meg a btrfs egy helyen lesznek...

Amúgy elég elkeserítő, hogy év végére várják az első early adoptereket. Tehát kb. 2-3 év, mire céges környezetben érdemes elkezdeni használni. Ez túl sok idő, akinek ez a funkcionalitás kell, maradni fog inkább az OpenSolaris-nál, esetleg BSD.

Szerencsére nem kell enned magad, mert az Oracle és Chris már megválaszolta ezt a kérdést:

A linux-btrfs@ levelezési listán Chris a következőket írta:

Idézet:

Hello mindenki,

Csak egy gyors megjegyzés a nemrég bejelentett Oracle általi Sun felvásárlással kapcsolatban. Ez nem változtatja meg az Oracle Btrfs-sel kapcsolatos terveit egyáltalán és a Btrfs továbbra is kulcsfontosságú projekt számunkra.

Kérlek folytassátok a btrfs hozzájárulásaitokat és teszteljétek a jövő kiadásokat.

Tehát 1) egyrészt elmondták már, hogy a btrfs marad 2) a kódja GPL, része a mainline kernelnek, a Linux fejlesztők - köztük az ext3/ext4 fejlesztő Tytso - deklarálták ez _lesz_ a következő generációs Linux fájlrendszer 3) Intel, Red Hat, IBM és önálló fejlesztők fejlesztik már jelenleg is 4) a Red Hat felajánlotta hogy, jócskán kiveszi a részét a fejlesztésből

Magyarul, nem feltétlen számít az, hogy mit csinál az Oracle.

HTH

--
trey @ gépház

A cikkben:

"...The option of encrypting data on the fly is also planned."

Kár hogy még csak terv szakaszban van, jó lett volna ha már -block szintű ?- titkosítással is lehetett volna tesztelni.