Eltávolították a "highly experimental" jelzőt a btrfs-ről

Fájlrendszer, NAS, storage

A btrfs fejlesztése jó ideje folyik. Hosszú időn keresztül, egészen pár nappal ezelőttig figyelmeztető üzenet volt olvasható a kernel konfigurálásakor a Kconfig HELP szövegében: "Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET - FINALIZED." Sokakat ez visszatartott a fájlrendszer tesztelésétől, felhasználásától, pedig egyes Linux disztribútorok már jó ideje azt kommunikálták, hogy szerintük a btrfs éles felhasználásra kész.

Tavaly tavasszal az Oracle jelentette be, hogy a btrfs "production ready", a SUSE ugyanakkor pedig közölte, hogy kereskedelmi támogatást nyújt a következő generációs Linux fájlrendszerhez.

A két cég által közölteknek ellentmondani látszott az, amit a kernelkonfigurációt végző láthatott egészen 2013. januárjáig. Ugyanis addig kellett várni, amíg a btrfs-ről eltávolították az "EXPERIMENTAL" jelzőt. Viszont ekkor még rajta maradt a kissé nyugtalanító "Unstable disk format" megjegyzés. Ezt a fejlesztők néhány hónappal később eltávolították és a fájlrendszer mellett immár a "Btrfs filesystem support" volt olvasható.

Azonban a HELP szövege továbbra is tartalmazta a "Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET - FINALIZED." szöveget. Egészen november 21-ig, mikor is a SUSE alkalmazásában álló David Sterba alábbi változtatását Chris Mason commit-olta:

btrfs -

A változtatás a következő megjegyzéssel került bele a mainline kernelbe:

"Almost all of these are bug fixes. Dave Sterba's documentation update is the big exception because he removed our promises to set any machine running Btrfs on fire"

Akit eddig az tartott vissza a btrfs kipróbálásától, hogy a kernelkonfig vészjóslóan nyilatkozott róla, annak immár nincs oka arra, hogy húzódozzon tőle.

( freeoli v | 2013. 12. 05., cs – 13:55 )

A help tartalma általában nem határozza meg a bitek biztonságérzetét a lemezfelületen. Így érthető, hogy óvatosabbak mert anno a reiserfs ...

Valakinek volt mostanában komoly gondja vele? Használja valaki komoly helyen?

( szotsaki | 2013. 12. 05., cs – 20:18 )

A következő a tapasztalatom vele, átlagos otthoni felhasználás esetén, RAID nélkül:

- A tömörítés nagyon jó (lzo), és észrevehetetlenül működik (valószínű, hogy gyorsít).
- A Copy on Write biztos jó, de sajnos ez az, ami miatt rengeteget lassul az egész rendszer az idők folyamán. Érdemes azokat a mappákon kikapcsolni a CoW-ot, amik nagy fájlokat tartalmaznak és gyakran változnak. Ilyenek mint: adatbázis, adatbázis binlogok, virtuális gépek, journald könyvtára (/var/log/journal), Steam mappa :) ($HOME/.local/share/steam). Egy példa erről: 28 000 töredék keletkezett egy fél év alatt a naplókból, és a jelenlegi rendszernaplók előbányászása (journalctl -b) másfél percig tartott. Egy töredezettségmentesítés után újra pár másodperc lett.
- A töredezettségmentesítés minden egyes eddigi kernelverzióban pánikot okoz, ezért érdemes kivárni a 3.13-ig vele.
- A "cp --reflink=always" egy remek találmány; így, és a tömörítéssel tudok 2*50 GB-os szövegfájlt szumma 4 GB-on tárolni.
- Ha tönkrevágod az egész rendszert, akkor a btrfsck segít. Ha mégsem, akkor el tudod küldeni a fejlesztőknek a fájlrendszer vázát, ők kiegészítik a btrfsck-t, és onnantól kezdve segít. Ez régen kétszer esett meg velem.
- Mindig a legfrissebb kernellel kell nekivágni. A régieket egyrészt nem is támogatják, másrészt elég bugosak.

Sebességben mára kezd eljutni egy ext4-hez napi szinten is, de van jó pár nyűgje, amit be kell tartani. Például egy teljes töredezettségmentesítés után érdemes bekapcsolva hagyni az autodefrag-ot fstabban.

Ellenben a nyújtott szolgáltatásokban lehagyja azt, így kb. megvan az egyensúly otthoni felhasználásnál.

A fejlődése szemmel látható minden kernelverziónál.

Személy szerint backup lemez fájlrendszereként teljesen bátran ajánlom mindenkinek egy 3.12-es kernel mellett az automatikus tömörítés, a 0 helyigényű új snapshotok (+ a változások), illetve a hamarosan érkező offline deduplikáció miatt. Szerveren (vagy más nagy rendelkezésre állású helyen) ettől függetlenül adatot még nem bíznék rá. El nem veszik, de ha valami gond van, akkor lassan lesz meg.

--
The Elder Scrolls V: Skyrim

Nekem egy szűkös 16 Gb-os ssdn a érzésre Btrfs és az ext4 között ég és föld a különbség a btrfs javára.

Egyébként a trim-et mindkettő támogatja, és mindkettőnél kézzel kell bekapcsolni, tehát élettartam szempontjából kb tökmindegy. Ezen kívül a btrfs-nek van ssd optimalizációja - ez elvileg csinál jóságokat, nem tudom mit számít.

Az jutott eszembe, hogy az ilyen optimalizációk mennyire segítenek akkor, ha full disk encryption van. Munkával kapcsolatos vagy privát gépen preferálom az ilyesmit.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( uid_6201 v | 2013. 12. 06., p – 16:11 )

Köszönöm, hogy megosztottad velünk a jó hírt. Ezen felbuzdulva a legutóbbi stabil kernelt lefordítottam (3.12.3), majd e2fsck után nekiugrottam egy

btrfs-convert /dev/md2

műveletének. Vigyázat! Több órás művelet mert a teljes tartalmat ellenőrzőösszeggel látja el, így az összes fájlt felolvassa.

Az eredmény: kevesebb tárhely. A df kimenete

Ext4 (konverzió előtt):
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md2 720944140 243763224 440535960 36% /data

btrfs (konvertálva):
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md2 732571492 256053992 317901352 45% /data

Ezután letöröltem az ext4 snapshotot.
btrfs subvolume delete /data/ext2_saved/

És most a btrfs (snapshot törlés után):
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md2 732571492 244159192 325879624 43% /data

Miért maradt ilyen kevés a btrfs konverzió után a hely? Valahol van még valami snapshot?

Emlekeim szerint df btrfs eseten sacometernek jo csak:

root@stor-pod-1:~# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ssd-root 22G 8.8G 12G 43% /
root@stor-pod-1:~# btrfs fil df /
Data: total=11.01GB, used=7.70GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.00GB, used=566.80MB
Metadata: total=8.00MB, used=0.00

Javul a helyzet. Felcsatoltam a partíciót compress-force=zlib,autodefrag opciókkal, majd végrehajtottam egy

btrfs balance /data

parancsot. Órákig fut ez is, ráadásul "no space left" üzenettel le is állt. Ez utóbbit nem értem. A helyzet most:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md2 732571492 243967400 487949412 34% /data

A szabad hely látszólag elérte az ext4-nél tapasztalható helyet. Viszont csak inodetömörítéssel együtt (ami egyébként nem futott teljesen végig).

( budee | 2013. 12. 09., h – 17:47 )

Roviden negativ tapasztalatok:
* compress=lz4 silent megeszi az adatod. 2 gepen kapcsoltam be egyszerre a btrfs compress-t. Mindket gepen ujra kellett csinalnom a filerendszert par nappal kesobb. Kernel panic-ok es hibas fileok keletkeztek kozben.
* a checksum nem sokra jo. Igaz, hogy csinal checksum-ot, de ha az adat nem felel meg a checksum-nak, akkor siman 0 byte-okat ad vissza (a rendes viselkedes itt az lenne, amit a ZFS is csinal, hogy IO errort dob). Ok, annyira jo, hogy beirja a kernel logba a checksum errort.

A pozitivumok:
* A raid funciok tok jo, a notebookomon semi-online csereltem HDD-rol SSD-re. Bedugtam USB-n az uj diszket, btrfs device add..., majd btrfs device delete..., notebook kikapcsol, diszkek kicserel, ujra bekapcsol. Persze kellett grub reinstall is.
* Snapshot
* Grub2 tamogatja, igy nem kell kulon /boot ha btrfs root van.

A pozitivumok kozul egyik sem olyan ami nem lenne meg a ZFS-ben is. Egyedul annyiban jobb a btrfs, hogy kevesebb memoriat eszik. Igy VPS-eken altalaban btrfs-t hasznalok, fizikai gepeken altalaban ZFS-t.