Ako som vyskúšal súborový systém Btrfs

Pred pár dňami som preinštaloval mój laptop. Vzhľadom na to, že som veľa počul o novom súborovom systéme Btrfs pre Linux, rozhodol som sa ho vyskúšať. Rád skúšam nové veci a nové technológie. 🙂

Debian inštalátor ponúkol pri inštalácii možnosť použiť Btrfs, tak som nakonfiguroval štandardné 3 blokové vrstvy takto:

  • disk rozdelený na 2 oblasti (/dev/sda1 – /boot, /dev/sda2 – dm-crypt)
  • LVM v šifrovanom oddieli /dev/sda2
  • niekoľko logických diskov v LVM a btrfs na /dev/vg0/home

Btrfs som teda použil namiesto mnou obľúbeného XFS.

Do domovského priečinku som si nakopíroval asi 1 milión súborov v objeme cca 200G a začal používať novú Debian inštaláciu. Priebežne som si doinštalovával potrebné balíky.

Po pár dňoch som ale zaregistroval nepríjemné pomalé odozvy prehliadača, napr. pri prepnutí záložky, posune stránky smerom nadol a pod. Na pomalšie odozvy som zvyknutý (množstvo pluginov vo Firefoxe, šifrovaný disk, málo RAM a veľa swapu), ale toto bolo „zamŕzanie“ v dĺžke cca 20 – 30 sekúnd a bolo naozaj časté.

Tak sa googla spýtal, čo si on myslí o slovnom spojení btrfs LVM crypt performance problem a klikol som na prvý odkaz.

Autor testoval výkon niektorých súborových systémov pri rozbaľovaní takmer 500G archívu. Pomerne dobrý záťažový test. Jeho merania potvrdili to, čo som ja zaregistroval s mojim prehliadačom Firefox (resp. Iceweasel).

 

zamŕzanie Btrfs

 

Graf zobrazuje počet prečítaných bajtov programom ‚tar‘ v závislosti od času. Schody v grafe (vodorovné úseky) teda znamenajú, že počas niekoľkých sekúnd bol proces zablokovaný. Presne toto som pozoroval aj s mojím prehliadačom, ktorý sa lockoval pravdepodobne počas zápisu stavu mojej session na disk (používam rozšírenie Session Manager).

Postup bol teda jasný: prechod späť k XFS.

Vytvoril som si teda v LVM ďalší oddiel, naformátoval na XFS (mkfs.xfs /dev/vg0/home-xfs) a rsyncom začal prenášať dáta z Btrfs na XFS.

rsync -aAhH --progress /home/ /mnt/home-xfs/

Ale čakalo ma ďalšie prekvapenie. Ako bežal výstup z rsyncu, náhodom som si všimol I/O error – rsyncu sa nedarilo niektoré súbory prečítať a v dmesg sa objavili takéto chyby:

[523437.603247] btrfs csum failed ino 18694 off 0 csum 3125679904 private 3093459267
[523437.603317] btrfs csum failed ino 18694 off 4096 csum 3663672300 private 3109476464
[523437.603372] btrfs csum failed ino 18694 off 8192 csum 299660372 private 568202748
[523437.603423] btrfs csum failed ino 18694 off 12288 csum 4241078207 private 2357947352
[523437.603474] btrfs csum failed ino 18694 off 16384 csum 460327346 private 692404878
[523442.646546] btrfs_readpage_end_io_hook: 3330 callbacks suppressed
[523442.646550] btrfs csum failed ino 44662 off 0 csum 2292054702 private 3760533057
[523442.646615] btrfs csum failed ino 44662 off 4096 csum 2898331831 private 998709990
[523442.646995] btrfs csum failed ino 44662 off 36864 csum 2065404657 private 3864019693
[523489.323546] btrfs_readpage_end_io_hook: 1134 callbacks suppressed
[523489.323551] btrfs csum failed ino 232260 off 191889408 csum 3501019314 private 2010173346
[523489.323673] btrfs csum failed ino 232260 off 191893504 csum 113509468 private 2358812383
[523489.323727] btrfs csum failed ino 232260 off 191897600 csum 513430729 private 479417494

Skvéle, že nás Btrfs upozornil na chybné kontrolné súčty, ale súbor by mohlo ísť nejako prečítať (veď čo ak je chyba práve v kontrolnom súčte 🙂 ). Tak som aspoň podľa čísla inódov dohľadal, o ktoré súbory sa teda jedná:

Find naštastie fungoval a vypísal mená súborov, ktoré nešlo z Btrfs prečítať. Naštastie som vedel súbory obnoviť z inej zálohy. Ale strata poniektorých z nich by ma dosť mrzela. Zaujímavé bolo to, že to boli súbory, ktoré sa nakopírovali na Btrfs iba raz a nepracovalo sa s nimi, ani sa do nich nezapisovalo. Žeby to bola chyba hardisku? Ale žiadne chyby zápisu na disk som v dmesg nenašiel. Skúsil som teda na Btrfs pustiť btrfsck. Ten iba vypísal zoznam nejakých chýb, ale žiadnu z nich nevedel opraviť. Ani manuál nič nehovorí o tom, ako chyby na Btrfs opraviť.

## btrfsck /dev/twinky/home-btrfs
root 5 inode 4124 errors 400
root 5 inode 4493 errors 400
root 5 inode 921855 errors 400
root 5 inode 922009 errors 400
root 5 inode 922010 errors 400
found 205402562560 bytes used err is 1
total csum bytes: 198926716
total tree bytes: 1701605376
total fs tree bytes: 1395453952
btree space waste bytes: 482401170
file data blocks allocated: 207554252800
 referenced 203629551616
Btrfs Btrfs v0.19

Pre istotu som teda doinštaloval nástroje na kontrolu disku, spustil SMART test a šiel spať.

## apt-get install smartmontools hddtemp hdparm sdparm
## smartctl -a /dev/sda
## smartctl -t long /dev/sda

Smart test nezistil žiadne problémy, ktoré by potvrdzovali chybu disku. Aj bezproblémové správanie s XFS filesystémom to potvrdzujú. Preto si myslím, že problémové správanie mal na svedomi kód Btrfs.

Ponaučený z krízového vývoja som si nainštaloval nástroje na validáciu obsahu súborov.

0 názorov na “Ako som vyskúšal súborový systém Btrfs

  1. Heron

    Nemůže být příčina těch nesprávných checksumů právě v použití LVM a cryptu? Osobně používám btrfs přímo na disku (dva disky v btrfs raid1) a zatím jsem na nic takového nenarazil (tím neříkám, že tam nemůže být problém, přece jen je to devel).

    1. Aleš Kapica

      Taky si myslím že to bude použitou kombinací, která mi přišla docela divoká. Fyzický disk -> kryptovací vrstva -> LVM -> Btrfs

      Kdyby bylo to LVM přímo nad fyzickým diskem, nebo tam byl ještě alespoň mezi kryptovací vrstvou a LVM SW raid, který by pořešil případné nesrovnalosti vzniklé na kryptovací vrstvě, ale takhle..

      Btrfs je FS který má vlastnosti LVM zabudovány v sobě. A nejsem si jist, jestli mu kryptování „pod zadkem“ dělá zrovna dobře, jelikož data interně komprimuje přes lzma.

      1. Neználek

        Jen pro úplnost, Btrfs dělá kompresi pokud se zapne a je to teď zlib nebo lzo, tedy ne lzma (které by mělo o dost lepší kompresní poměr).

        Jinak, používám Btrfs standardně přímo pro root už řádově rok bez jakékoliv ztráty dat, i když někdy mám pocit pomalosti (to ale může být způsobeno i něčím jiným).