Chris Mason kérte a btrfs mainline kernelbe való beolvasztását

Fájlrendszer, NAS, storage

A btrfs névre hallgató következő generációs Linux filerendszer fejlesztése olyan szakaszba érkezett, hogy vezető fejlesztője, Chris Mason elérkezettnek látta az időt arra, hogy beküldje az LKML-re, kérve beolvasztását a mainline kernelbe.

A fejlesztő jelezte hogy nemrég tesztelte a forrást Linus git fájával és azt rendben levőnek találta. Andrew Morton viccelve kérte számon a patcheket, mire Chris útbaigazította. A mainline kernelbe kerülés nem olyan egyszerű feladat, főleg ha új filerendszerről van szó. Andi Kleen szerint lenne még mit dolgozni rajta a beolvasztás előtt. Matthew Wilcox más véleményen van. Szerinte már be lehetne olvasztani. Látszólag Christoph Hellwig számára is vannak nyitott kérdések. Döntés még nem született, de az mindenesetre jó jel, hogy elindult a folyamat.

( Boobek | 2009. 01. 03., szo – 22:55 )

Hát úgy néz ki, hogy a következő rendszer újrarakásnál már dönthetek róla, hogy melyik új fájlrendszerrel szeretnék szívni/meglenni!:)
Régen volt már ilyen.. Bár igazából sok teljesítménybeli javulást nem várok a dologtól.. a gépem lassú:P

(nem néztem nagyon utána, de nem véletlenül Andi Kleen-ről van szó?)

( godot v | 2009. 01. 03., szo – 22:58 )

Ha jól látom a kernel core-on semmit sem kell módosítani a beolvasztáshoz, tisztán külső modulként fordul. Innetől nem értem a problémát.

Az, hogy innentől kezdve másoknak is karban kell tartaniuk ezt a kódrészletet, emaitt nem mindegy, hogy pl. hány felesleges wrapper réteg van a lockoláshoz, mennyire jól dokumentált a forrás, milyen stílusú az ioctl API. Illetve, ha később a kernel core-on módosítanak valamit (most konkrétan a spinlock, mutex API-król van szó), akkor nyilván át kell írni ebben a modulban is az API-t hívó részeket. Olvasd el a linkelt leveleket és abból látni fogod a konkrét kifogásokat.
---
Linux is bad juju.

( bounty v | 2009. 01. 03., szo – 23:59 )

Pont ma konvertáltam át az otthoni gépemet cakkpakk ext3-ról ext4-re, a következő már a btrfs lesz, kíváncsi vagyok mikor lesz stabil.

( nevergone v | 2009. 01. 04., v – 00:11 )

Véglegesítették a lemezformátumot?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

A wiki szerint nem, de azt ritkán frissítik. De nem feltétlen kell véglegesnek lennie, elég ha az új változtatások hozzá már olyanok lesznek, amelyek már biztosítják a visszafele kompatibilitást, azaz változhat, de már nem olyan nagy mértékben. Megkérdeztem, meglátjuk mi a válasz :)

--
trey @ gépház

Ha jól emlékszem, akkor volt tervben ilyen funkció megvalósítása. Az volt a terv, hogy amíg nem jutnak el ilyen szintre, addig nem nyomják a stuffot beolvasztásra. Nem hiszem, hogy probléma lenne nekik ezt program futtatásával megoldani, ha megoldották ezt.

--
trey @ gépház

Na akkor a kérdésemre a válasz:

> Does this means that disk format finalised or at least backward
> compatible?

We're making every effort to avoid new disk format changes now (that are
not backward compatible). Only a critical bug would result in a disk
format change now.

Azaz, megtesznek minden lehetségest, hogy mostantól újabb lemezformátum változás ne legyen. Csak kritikus bug okozhatna innentől kezdve lemezformátum változtatást.

--
trey @ gépház

Jelenleg még megteheti, hiszen ha be is olvasztják a mainline kernelbe, akkor is "btrfsdev" lesz. Azaz nem lesz ajánlott éles felhasználásra, a beolvasztás a fejlesztés megkönnyítését lesz hivatott biztosítani a fejlesztés ezen szakaszában :)

Annak ellenére, hogy nekem stabilan megy (rendszeres rsync nem rohasztotta még meg), az allokációs kód sem komplett, ezért egyelőre él még az a limitáció is, hogy a teljes lemezterületnek csak a 75%-át lehet használni, stb.

--
trey @ gépház

( uid_228 | 2009. 01. 04., v – 11:12 )

Tudom, hogy "apples and oranges", de ha már többé-kevésbé beolvasztották és stabilnak van kikiáltva, akkor örülnék, ha valaki ráérő csinálna egy ZFS-Btrfs-tesztet. :)

--
"Only an expert can deal with the problem"

( gUHU | 2009. 01. 04., v – 12:45 )

Akkor a kérdés, hogy otthoni desktopra mit érdemes rakni? ext3/4 vagy btrfs?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

az ext2 nem naplózó, az ext3 csak annak van csúfolva, de megvan az idegesítő boot közbeni ellenőrzés még mindig, ext4-et nem ismerem, reiserfs a --rebuild-tree után is tud kernel panic-ot okozni (reiserfs partíción fájl, rajta reiserfs), még nem nagyon múlt el év anélkül, hogy ne lett volna gondom vele. XFS meg egyetlen kernelverzióban volt rossz, úgy két éve. Egy erősebb gépen (egymagos 1.8-2 GHz és 1 GiB memória mellett) meg nem lassú :)

Nem is lassusagra ertem ezt most pontosan.. Szimplan az zavar hogy felpakolok barmit a gepre (mindegy milyen eros gep, mindegyik gepen megcsinalta a lakasban (1.6ghz atom, 2.0ghz c2d centrino, 2.4ghz c2q, 2.8ghz p4d), hogy barmifele adatot irtam ra (pl par sorozat), utana meg elkezdtem nezni oket, szaggatott a film. Zene is ilyen, a tobbi program meg szintugy belassul. Csak akkor volt kepes normalis mukodesre mikor minden uj adat irasakor toredezettsegmentesitettem. Masik gondom hogy a kisgep kb 3napig fut ext3-al, semmi cpu terheles, semmi melegedes. XFS-el mar orak utan elkezdett a vinyo melegedni, nem is picit, na meg a load is rendesen megnott. (kernel<=2.6.26/27 -el hasznaltam xfs-t)

Amiota linuxozom, reiser-t hasznalok, gondom nem volt vele. XFS-be a quota support meg mindig pocsek es aluldokumentalt, raadasul ezen felul semmilyen plusz feature-je nincs a reiser-hez kepest. Volt mar rebuild-tree, rebuild-sb, es meg sosme tortent semmi.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem ert volna fulig a szad ha nem nalam tortenik..ehhh. (Nem hinnem ez is "csak nalam tortenik meg" szintu bug..ohm..feature (elnezest..errol a csodas FSrol nem szabad ilyesmit irni). Anno mikor korbelestem mindenki dicsoitette, ezert alltam at XFS-re.. a gondok hamarosan kezdodtek mikor hosszutavon szerettem volna hazsnalni.) (ps.: "Ne etesd".. lehet jobb volna..)


/dev/sda1 /boot
actual 52, ideal 51, fragmentation factor 1.92%
/dev/sda3 /
actual 102901, ideal 102542, fragmentation factor 0.35%
/dev/sda4 /var
actual 9072, ideal 8012, fragmentation factor 11.68%
/dev/sda5 /tmp
actual 14, ideal 14, fragmentation factor 0.00%
/dev/sda6 /home
actual 34296, ideal 33211, fragmentation factor 3.16%
/dev/sda7 /usr/data
actual 232964, ideal 232428, fragmentation factor 0.23%

2 vagy 3 éves XFS partició... a data nem kicsit kap naponta pár git pull-t olyan 8 git tree-re, és igen, vannak rajta filmek és zenék is, ÉS nem lassul be

szerk.:
defrag még egyszer sem volt rajta
___
info

Desktopra ext3 elég szar, 200 megás fájlok már képesek 100+ darabra töredezni, így torrentezésre alkalmatlan. De a nagyobb postaládák kezelésére is, ha a levelezőprogram egy fájlban tárolja a leveleket (evolution, thunderbird meg minden, ami mbox formátumot használ), a firefox sqlite adatbázisai szintén szétesnek. Az NTFS-t legalább defragolni lehet win alatt, itt még azt sem. Egy-egy nagyobb fájl törlése vagy létrehozása pedig rengeteg ideig tart. Szóval csak hajrá, remélem ext4 lesz már a következő ubuntuban az alap. Vagy az se oldja meg a fenti problémákat?

Ja, és ezeket úgy csinálja, hogy 15%-ot mindig szabadon hagyok.

így torrentezésre alkalmatlan
Ez a torrent hibája is... Sparse fájlok létrehozása úgy hogy mindig csak ~16kB-os darabokat ír teljesen random sorrendben, ezt semmi sem fogja tudni egyben tartani. Illetve de: állíts be teljesen előre allokált fájlt a torrent kliensben és akkor egyben marad. Az ext4-ben is valami garbage collection szerűséget próbálnak csinálni a fokozatosan összeálló sparse fájlok töredezésének kivédésére, kíváncsi vagyok ez mekkora overheadet jelent.

A törlés lassúsága viszont sajnos tényleg jogos kifogás.
---
Linux is bad juju.

Engem is érdekelne ez a kérdés, de inkább más formában. Konkrétan az ext3 számomra nem elég biztonságos. Volt hogy egyszer egy hirtelen áramkimaradás után rátoltam egy fsck-t a particióra (ro volt), és a fájlok közül annyit nem tudott visszaállítani, hogy gyakorlatilag a rajta levő rendszert újra kellett telepíteni. Emlékszem, régen ext2-vel soha nem volt ilyen mértékű adatvesztés, pedig áramszünet akkor is volt, több is...

Szóval: ext4 biztonságosabb módon tud-e adatot tárolni majd, mint az elődje? Vagy ha nem, a brtfs hozza-e majd a kellő megbízhatóságot?

Épp rendszer upgrade közben állt le a gép? Mert az pech.

Belegondoltam a fájlrendszer korrupció eseteibe és a következő okfejtésre jutottam. Nem vagyok biztos benne, hogy igazam van, de szerintem:

A sima fájlrendszerek eleve nem támogatnak tranzakciókezelést, tehát ha mondjuk úgy upgradelsz rendszer fájlokat, hogy egyszerűen a helyére másolod az új változatot akkor a fájlrendszer helyes működése ellenére is elképzelhető (áramkimaradással félbeszakított upgrade esetén), hogy a fájlnak egy félig odamásolt változata marad a fájlrendszeren. Ha ez a rendszer működéséhez alapvető fájl (pl init) akkor a rendszer többet nem indul el. Tehát nem feltétlen a fájlrendszer hibája ha ilyen előfordul.

Nem, nem upgrade közben történt a leállás. Nem tudom pontosan mit csináltam, de semmi olyat, ami a rendszerfileokat érintené.

Csak a hiba kijavításához kellett az upgrade, mert ugye egy upgrade közben kb. az összes rendszerfile lecserélődik, amik már nem lesznek corruptak. Ez az eset kicsivel a frugalware 0.9-es stabil verziójának megjelenése előtt történt, és amikor kijött a 0.9, akkor az upgrade maga orvosolta a problémát.

A ReiserFS a mainline kernelben a mai napig karbantartott, bugfixelt filerendszer. Nem fejlesztik, nyilván új szolgáltatásai nem lesznek.

A Reiser4 sosem lett a mainline kernel része és nem sok esélyt látok arra, hogy valaha is az lenne.

Hivatalos oldal - ha a namesys.com-ra gondolsz - nem létezik.

--
trey @ gépház

ki fogtok röhögni, de kb 2 hónapja JFS-el tettem újra az ubuntumat, és az az érzésem, mintha gyorsabb lenne, folyamatosan megy a torrent, virtualboxszal xp, mellette emesene, firefox, és filmnézésre meg mplayer.

Többször sikerült már újraindítanom kilépés nélkül (kirántottam véletlen a falból a vezetéket), utána semmi lemezellenőrzés, semmi hiba, magam sem értettem, hogy ez miért van így:)

( szemet | 2009. 01. 05., h – 11:36 )

Nekem lenne, egy kérdésem, utánanéztem és a Hup wiki szerint btrfs helyben konvertál etx3-ról. Ez stabil?

De a fontosabb kérdés, hogy először ext3->ext4 konverziót tervezek, és hogy tervezik-e majd támogatni a migrációt ext4-ről is? Vagy ha jót akarok magamnak hagyjam ki az ext4-et?

(javítva: kis adalék, a btrfs wiki főoldalán van egy link "Conversion from Ext3 and Ext4", igaz hogy ahova mutat még csak az Ext3-ról van szó, de link címe azért ígéretesnek tűnik...)

"Nekem lenne, egy kérdésem, utánanéztem és a Hup wiki szerint btrfs helyben konvertál etx3-ról. Ez stabil?"

A btrfs-sel kapcsolatban még semmi sem stabil abban az értelemben, hogy élesben ajánlanák a fejlesztők.

"De a fontosabb kérdés, hogy először ext3->ext4 konverziót tervezek, és hogy tervezik-e majd támogatni a migrációt ext4-ről is? Vagy ha jót akarok magamnak hagyjam ki az ext4-et?"

Ahogy megválaszoltad magadnak, tervezik. :)

--
trey @ gépház