Alapértelmezett fájlrendszer lehet a Fedora 16-ban a btrfs

A Red Hat alkalmazásában álló Josef Bacik komoly mértékben részt vesz a Chris Mason vezette btrfs projektben, amelynek az a célja, hogy megalkossa a következő alapértelmezett Linux fájlrendszert, kiváltva az ext-et. A fejlesztés Josef szerint elérkezett ahhoz a szakaszhoz, hogy hamarosan elkészülnek a működő fsck eszközzel, ezért elérkezettnek látta az időt arra, hogy a btrfs Fedora-s jövőjéről ejtsen néhány szót. A fejlesztő célja a következő:

  • a Fedora 16 alapértelmezetten a btrfs fájlrendszert szállítsa
  • a Fedora 16 az LVM kötetkezelő nélkül érkezzen és helyette alapértelmezetten a btrfs beépített kötetkezelő funkcionalitását használja

A fejlesztő egyelőre vitára bocsátotta a kérdést. Hogy milyen fejlesztéseket kell még elvégezni ahhoz, hogy ezt a célt el tudják érni, elolvasható Josef levelében.

Hozzászólások

"hamarosan elkészülnek a működő fsck eszközzel,"
Hajrá! Erre várok fél éve!

Még inkább örülnék egy olyan btrfs-nek, amit *nem kell* fsck-zni.

"Ha mindezek hibátlanul és gyorsan fognak benne működni" <- ez a lényeg.
Nekem speciel fél éve áll egy 1,5TB-os image-em, ami hibássá vált, és a Q fsck-juk nem tud semmit kezdeni vele. Mindez a production ready felkiáltás utáni release-zel.
Szóval, 3 anyja legyen annak, aki ezt storage-ra teszi az elkövetkező 3 évben.

"Mindez a production ready felkiáltás utáni release-zel."

Nem "production ready". Nem tudok olyan kijelentésről, hogy már éles rendszeren bátran használható, illetve a btrfs Wiki is arról ad tanúbizonyságot, hogy bizony még erősen fejlesztés alatt áll.

(Igen, volt róla szó, hogy majd ha a diszkformátum véglegessé válik, akkor majd az lesz. Egyelőre nem vette le róla Mason az "experimental" jelzőt. Erre többször is felhívták a figyelmét, ígérte is, hogy leszedi majd a következő git pull-ra, de nem szedte, mert mindig volt valami, ami miatt nem tette.)

--
trey @ gépház

Inkább húzza egy kicsit tovább a fejlesztést minthogy hamis biztonságérzetbe ringassa a felhasználót.

Egyébként sem értem, egyes esetekben hogy képes valaki pontos határidőt vállalni egy fejlesztésre amikor gőze sincs hogy milyen hibákkal, gondokkal fog találkozni közben és mennyit fog vacakolni a megoldásukkal.

"Felmerülhet a kérdés, hogy vajon a btrfs - amely még a friss kernelekben is "experimental" jelzővel van ellátva - elég stabil-e erre a feladatra?

Arjan erre a kérdésre válaszolva elmondta, hogy gyakorlatilag tavaly szeptember óta használják a btrfs-t a build-jeikben és kiadott MeeGo kódokban is btrfs-t használnak. Arjan szerint a btrfs tavaly augusztus/szeptember óta nagyon stabil az összes tesztjükben, az általa kínált szolgáltatáscsomag pedig nyilvánvalóan nagyon vonzó."
.
tavaly augusztus/szeptember == 2009.09

Nézzük. Arjan szerint stabil. MeeGo alá. Mit jelent ez? Hogy egy külsős ember szerint mobiltelefon workload alá szerinte stabil. Erre alapozva eszembe nem jutna éles rendszerre btrfs-t használni, hacsak az nem olyan terhelés, mint amit egy mobiltelefon ró a fájlrendszerre. Szerintem egy mobiltelefonon az adatbiztonság kicsit más kategória, mint egy production szerveren.

--
trey @ gépház

"Tehát akkor a Fed16 is experimental lesz, igaz?"

Feltehetően igen.

"Mellesleg tök mindegy, hogy az vagy sem, elég régóta köszörülik ezt a B tré FS-t, és így is csak egy fostalicska."

Minden bizonnyal igazad van. Én nem használom, utoljára kb. 2008-ban néztem rá.

--
trey @ gépház

A Fedora mindig is tartalmazott experimental kodot, viszont elegge mukodokepesre osszereszelve.

Teljesen ertheto, hogy a te szemelyes benyomasaid negativ velemennye formalodnak benned, de ez nem azt jelenti, hogy a technologia szar. Lasd XFS (a filerendszer): hosszu evekig hallgattam, hogy az XFS szar, mert bizonyos rendszereken ugy borult ossze, hogy orom volt nezni (nem).

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Szerintem egy mobiltelefonon az adatbiztonság kicsit más kategória, mint egy production szerveren.

Ez netto marhasag, ugyan mas-mas okokbol kifolyolag, de ugyanolyan fontos mind a ketton, foleg ha a fogalmat nem csak az adat integritasara hasznaljuk. Egy telefonra meginkabb igaz az, h az ember a fel eletet lementi ra, kontaktokat, leveleket, satobbi, ahogy egy szerverre teszi akar ontudatlanul is. Csak amig ez utobbi altalaban valami zart helyen taroljak, addig az ember a telefonjat mindenhova magaval viszi, sokkal viccesebben valtozo kornyezeti hatasoknak van kiteve, a homerseklet valtozastol kezdve az enyveskezu etnikumig. Arrol nem is beszelve, h nem mindenki tudja/akarja/vanideje folyamatosan szinkronizalni az adatait valamilyen kevesbe serulekeny geppel.

---
pontscho / fresh!mindworkz

Jaja, teljesen ugyan az a kategória. Ezért is építenek RAID vezérlőt minden mobiltelefonba dedikált és global spare-rel, és valószínűleg ezért is költenek mobiltelefonok mentésére dollártíz- vagy százezereket a tulajdonosaik, hasonlóan mondjuk egy vállalati szerveren vagy storage-on tárolt adatok mentéséhez, ahol csak a mentő_szoftver_ értéke sokszor annyi mint egy fél teherautó mobiltelefon ára.

--
trey @ gépház

RAID nincs, de ujabban ecc es aes encrypted flash van, nem veletlenul terjednek a remote wipe es hasonlo szolgaltatasok, etcetc. Mint emlitettem mas szempontok szerint nezve hasonlo a fontossaguk. Es nem egy, nem csak vallalati juzert lattam besirni mert behalt az eszkoz es rajta volt a fel kapcsolat rendszere. Valoban megerdemli az ilyen, de ettol meg ugyanolyan igeny van ezeken az eszkozokon az adatbiztonsagra, mint egy-egy szerveren.

De amugy amen atyam. :)

---
pontscho / fresh!mindworkz

Ha elvesztem a mobiltelefonom és vele együtt az adataimat, akkor az egy ember számára probléma. Számomra. Mondjuk én spec. használok olyan advanked funkciókat, mint titkosítás és backup, de ez az én perverzióm. Ha elvesztem a rám bízott szerveren tárolt adatokat, az a "szerver" szóból adódóan nem egy ember számára probléma. Most voltam egy NetApp rendezvényen, ahol egy pók arról beszélt, hogy egy pár órás adatelérési probléma miatt egy nem kis cég konkrétan csődbe ment, Németország egyik fő autópályája pedig úgy beállt a kamionoktól, hogy nem lehetett rajta közlekedni.

Hát most összehasonlítottam a problémát. Ugyanaz. Tényleg.

--
trey @ gépház

"korszerű common partíció"

Ez annak idején nekem is okozott gondokat mert utálom a fat32-t, de más nem volt. Win98-al volt bajom. Egyszer valahogy melléírt a saját partíciójának és amikor legközelebb el akartam indítani a linuxot, az rögtön sírva fakadt. Ahogy lehetett külön merevlemezre tettem a kettőt. Most már nem lenne gond az adatátvitellel hiszen van ntfs-3g, viszont már nincs semmilyen win-em. :-)

Ha mindezek hibátlanul és gyorsan fognak benne működni akkor marad-e még valakinek hiányérzete?

3-5 év.

Addigra lehet ebből valami, stabilan. Még most sincsenek a stabilnak kikiáltható fázisban (hiszen még működő fsck-juk sincs), nincs aktuális verzió backportolva az aktuális long-term stable kernel verzióba, ergó nagyon sok felhasználónak még esélye sincs kipróbálni (vagy nagyon hamar kidobja).
Ha már a felhasználók nagy részének van esélye kipróbálni nem EXPERIMENTAL kódként (nem csak a Fedorában, hanem mondjuk az RHEL-ben is, meg nyilván más disztribúciókban is), root fs-ként működőképes, akkor onnantól számítva 1-3 év, mire igazán stabilnak lehet tekinteni, hogy rendes ember rá merje rakni a cuccait.

Nem, ez az idő azután számolódik, hogy az a valaki kitalálta és nagyjából (használhatóra) meg is csinálta; ekkor jön ugyanis a bugok kisikálása, és a bizalom meg a tapasztalatok begyűjtése. Na ez nem megy másnál sem gyorsabban, bármennyire hangosan üvöltik is egyesek, hogy "ez már kész és stabil". :)