Btrfs ztratilo část volného místa

[Petr Kratochvíl]

Zdravím,

řeším problém na jedné VPS s Debian 8 na Btrfs, které se mountuje těmito údaji v /etc/fstab:

Kód: [Vybrat]

UUID=824ec9a5-14ec-4df8-a9ec-a685f8903e9d /               btrfs   subvol=@,relatime,compress=zlib,recovery        0       1
UUID=824ec9a5-14ec-4df8-a9ec-a685f8903e9d /mnt/rootfs     btrfs   relatime,compress=zlib,recovery        0       2

A po připojení mount vypisuje:

Kód: [Vybrat]

root@web6:~# mount | grep btrfs
/dev/vda1 on / type btrfs (rw,relatime,compress=zlib,space_cache,subvolid=283,subvol=/@)
/dev/vda1 on /mnt/rootfs type btrfs (rw,relatime,compress=zlib,space_cache,subvolid=5,subvol=/)

Popis problému

Problémem je, že volné místo je o poznání menší než by se očekávalo:

Kód: [Vybrat]

Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/vda1             11G  9,3G  266M  98% /

11 GB > 9,3 GB + 266 MB

Používám sice subvolumy a snapshotování, ale dle mých zkušeností se při smazání snapshotu sice změní hodnoty u "užito" a "volno", ale nezmění se jejich rozdíl.

Btrfs v3.17, kernel 4.6.0: btrfs scrub

Zkusil jsem scrub, ale ten žádný problém nenašel:

Kód: [Vybrat]

root@web6:~# time btrfs scrub status /
scrub status for 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
        scrub started at Thu May 19 09:57:44 2016 and finished after 21 seconds
        total bytes scrubbed: 8.06GiB with 0 errors

Těch 8.06GiB je méně než v df výpisu, protože jsem mezi tím smazal jeden snapshot. Ještě uvedu verze:

Kód: [Vybrat]

root@web6:~# btrfs version
Btrfs v3.17
root@web6:~# uname -a
Linux web6 4.6.0-040600rc7-generic #201605081830 SMP Sun May 8 22:32:57 UTC 2016 x86_64 GNU/Linux

Btrfs v3.17, kernel 3.16.0: btrfs check

Zkusil jsem boot z live Debian 8 a 2x hned za sebou btrfs check. Obě spuštění vypsaly totéž a problém nevyřešily:

Kód: [Vybrat]

enabling repair mode
Fixed 0 roots.
Checking filesystem on /dev/vda1
UUID: 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
checking quota groups
Counts for qgroup id: 5 are different
our:        referenced 3197485056 referenced compressed 3197485056
disk:        referenced 3197485056 referenced compressed 3197485056
our:        exclusive 962273280 exclusive compressed 962273280
disk:        exclusive 902582272 exclusive compressed 902582272
diff:        exclusive 59691008 exclusive compressed 59691008
Counts for qgroup id: 283 are different
our:        referenced 6668357632 referenced compressed 6668357632
disk:        referenced 3244802048 referenced compressed 3244802048
diff:        referenced 3423555584 referenced compressed 3423555584
our:        exclusive 625876992 exclusive compressed 625876992
disk:        exclusive 625876992 exclusive compressed 625876992
Counts for qgroup id: 305 are different
our:        referenced 6244098048 referenced compressed 6244098048
disk:        referenced 2820542464 referenced compressed 2820542464
diff:        referenced 3423555584 referenced compressed 3423555584
our:        exclusive 200433664 exclusive compressed 200433664
disk:        exclusive 200433664 exclusive compressed 200433664
found 4242337340 bytes used err is 0
total csum bytes: 8077580
total tree bytes: 691945472
total fs tree bytes: 631996416
total extent tree bytes: 45137920
btree space waste bytes: 126257397
file data blocks allocated: 111147716608
 referenced 18110992384
Btrfs v3.17
extent buffer leak: start 138199040 len 16384
extent buffer leak: start 244596736 len 16384
extent buffer leak: start 714031104 len 16384
extent buffer leak: start 714620928 len 16384
extent buffer leak: start 716095488 len 16384
extent buffer leak: start 10012327936 len 16384

Na live Debianu jsem měl tyto verze:

Kód: [Vybrat]

root@debian:/mnt# btrfs version
Btrfs v3.17
root@debian:/mnt# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

Btrfs v3.12, kernel 4.6.0: btrfs check

Protože mi verze jádra na live připadala stará, nainstaloval jsem u sebe doma Linux Mint ve VirtualBoxu, v něm doinstaloval Btrfs a aktualizoval jádro, odvážně připojil blokové zařízení disku ve VPS jako lokální přes Network block device (NBD) a zkusil btrfs check. Opět 2x za sebou a opět obě spuštění vypsaly totéž a problém nevyřešily:

Kód: [Vybrat]

enabling repair mode
Checking filesystem on /dev/nbd0
UUID: 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 4496713856 bytes used err is 0
total csum bytes: 8077580
total tree bytes: 691945472
total fs tree bytes: 631996416
total extent tree bytes: 45137920
btree space waste bytes: 126258967
file data blocks allocated: 111146471424
 referenced 18109747200
Btrfs v3.12

Pro úplnost opět verze:

Kód: [Vybrat]

krato-VirtualBox ~ # btrfs version
Btrfs v3.12
krato-VirtualBox ~ # uname -a
Linux krato-VirtualBox 4.6.0-040600rc7-generic #201605081830 SMP Sun May 8 22:32:57 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

nospace_cache, clear_cache

S drobným odstupem času a po smazání nějakých snapshotů a vytvoření nových mě ještě napadlo zkusit na VPS mount options nospace_cache a clear_cache, detaily viz https://btrfs.wiki.kernel.org/index.php/Mount_options#Space_cache_control :

Kód: [Vybrat]

krato@web6:~$ mount | grep btrfs
/dev/vda1 on / type btrfs (rw,relatime,compress=zlib,nospace_cache,subvolid=283,subvol=/@)
/dev/vda1 on /mnt/rootfs type btrfs (rw,relatime,compress=zlib,nospace_cache,subvolid=5,subvol=/)

Ale nezdá se, že by to pomohlo, stále je rozdíl cca 1 GB:

Kód: [Vybrat]

krato@web6:~$ df /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       13619200 12443956    176908  99% /

13619200 = 12443956 + 176908 + 998336 kB

Závěr

Mám na Linuxu problém s částečným zmizením volného místa na Btrfs, které nevyřešil ani btrfs scrub a ani btrfs check.

Chtěl bych začít používat Btrfs všude kde mám nyní ext4, včetně ještě letos plánovaného datového RAID úložiště na více než 10 TB dat. Proto bych se rád naučil tento problém vyřešit jiným způsobem než zkopírovat data jinam, pak Btrfs partitionu znova vytvořit a na konec vrátit data zpět. U jedné VPS s 11 GB to problém není, ale však chápete.

Zkusil jsem nedávno na jednom 8 TB disku ZFS pod Linuxem přes http://zfsonlinux.org/, ale to je jiná kapitola kde jsem měl velké problémy s výkonem a skončilo to tím, že ten disk lze sotva používat read-only. Při připojení read-write se ihned začne přehrávat příliš náročná operace v jornálu mazání cca 2 GB souboru. Ale to tu nechme teď být, dejme teď šanci Btrfs.

Předem děkuji za jakékoliv konstruktivní rady.

[Reklama]

[Jenda]

Kód: [Vybrat]

Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/vda1             11G  9,3G  266M  98% /

11 GB > 9,3 GB + 266 MB

Pozor, df bez parametrů, případně df -h, když napíše K/M/G, tak tím myslí Ki/Mi/Gi. Skutečné k/M/G dělá df -H. (ne že by to souviselo zrovna s tímto problémem)

Zkoušel jsi btrfs fi df? Ukáže podrobnější informace o tom co kolik žere. Například metadata jsou defaultně dokonce duplikována, pokud máš hodně malých souborů a tedy hodně metadat, tak se to podle mě může projevit.

[JardaP .]

Volne misto chybi na kazdem FS. Abyste tomu predesel, musel byste na nej ukladat pouze soubory, ktere presne vyplni kazdou alokacni jednotku az do konce, protoze to, co by zbylo pak dela to, co schazi. Ono se to pri tisicich souboru nascita a predpokladam, ze ani Brtfs nema na toto zazracny lek. Me na Ext4 z 95 GB schazi skoro 5.

[Mirek Prýmek]

Používám sice subvolumy a snapshotování, ale dle mých zkušeností se při smazání snapshotu sice změní hodnoty u "užito" a "volno", ale nezmění se jejich rozdíl.

Spíš součet, ne?

Mám na Linuxu problém s částečným zmizením volného místa na Btrfs, které nevyřešil ani btrfs scrub a ani btrfs check.

Ještě bych to doplnil: máš problém s tím, že 1. různé verze se chovají zásadně odlišně 2. ani jedna neumí chybu opravit i když ji zdetekuje. To mi přijde jako daleko zásadnější problém...

Chtěl bych začít používat Btrfs všude kde mám nyní ext4, včetně ještě letos plánovaného datového RAID úložiště na více než 10 TB dat. Proto bych se rád naučil tento problém vyřešit jiným způsobem než zkopírovat data jinam, pak Btrfs partitionu znova vytvořit a na konec vrátit data zpět. U jedné VPS s 11 GB to problém není, ale však chápete.

Sám vidíš, že i při testování jsi narazil na velmi zásadní problém (porušení interních struktur FS není žádná prkotina), se kterým nehneš. Opravdu si myslíš, že v produkci nenarazíš ještě na spousty jiných, podobně zásadních? Na základě čeho si myslíš, že je btrfs production ready? Obnovovat 10T ze zálohy každou chvilku kvůli krámům btrfs by se mně teda nechtělo

Ale to tu nechme teď být, dejme teď šanci Btrfs.

To je trochu škoda. Pokud vím, používají zfsonlinux v produkci ve VPSFree, takže uchodit se to zjevně dá. Jestli by nebylo lepší to s nima konzultovat, než bojovat s btrfs?

[Lol Phirae]

S df u brtfs rozhodně nedostaneš žádné smysluplné informace; jak už bylo řečeno, je nutné použít btrfs fi df

P.S.

Zkusil jsem nedávno na jednom 8 TB disku ZFS pod Linuxem přes http://zfsonlinux.org/, ale to je jiná kapitola kde jsem měl velké problémy s výkonem a skončilo to tím, že ten disk lze sotva používat read-only. Při připojení read-write se ihned začne přehrávat příliš náročná operace v jornálu mazání cca 2 GB souboru.

Ehm, to je ten SMR "zázrak"? No, to se nedivím, že máš potíže s výkonem. Za to ale nemůže souborový systém. 

[Reklama]

[Petr Kratochvíl]

Díky za dosavadní cenné odpovědi. Reaguji alespoň v rychlosti:

Souborů a adresářů je dle "find / -xdev | wc" 411128 celkem, což při ztraceném cca 1 GiB by vycházelo ztracených cca 2432 B/soubor. To by smysl dávalo, ale přišlo by mi divné, že df nezapočítá do užitého místa i nevyužité místo souborů. Ok, zapomenu na df (což je škoda).

btrfs fi df

Kód: [Vybrat]

root@web6:~# btrfs filesystem df /
Data, single: total=9.70GiB, used=9.53GiB
System, DUP: total=40.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.60GiB, used=1.05GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=240.00MiB, used=0.00B

A jinak ano, to ZFS mám na "skvělém" 8 TB SMR disku. Ještě k tomu se zapnutou deduplikací. Dokud na něm nebylo moc dat, tak to nevadilo a před použitím jsem bohužel dělal jen sekvenční testy. Díky moc za článek mnohé vysvětlující.

Asi koupím ne-SMR 8 TB disk, provedu bitovou kopii dat na něj a budu doufat, že to dostatečně pomůže. Kdo by chtěl, může si o mém trápení se ZFS přečíst ve vlákně "ZFS pozastavuje zápis po zaplnění bufferu": http://forum.root.cz/index.php?topic=12850.0  Ten jsem "vyřešil" nebo lépe řečeno obešel snížením velikosti zápisového bufferu (echo 4000000 > /sys/module/zfs/parameters/zfs_dirty_data_max). Jenže nedávno mi v journálu uvízlo nedokončené mazání cca 2 GB souboru, které se začne řešit při každém read-write připojení v Linuxu a dříve než se vyřeší, přestane Linux reagovat. Je to ZFS partitiona šifrovaná přes dm-crypt/LUKS, ale i tak se mi ji podařilo zpřístupnit ve VirtualBoxu pro virtualizované FreeBSD a snad i Oracle Solaris, ale obojí odmítlo tu ZFS partitionu připojit (teď nevím proč přesně).

[Petr Kratochvíl]

Na základě čeho si myslíš, že je btrfs production ready?

Dobrá otázka.

Jednak se Btrfs objevilo v instalátoru openSUSE jako defaultní FS na / a pak jsem s Btrfs nikdy nenarazil na žádný problém ovlivňující data a to jsem na Btrfs loni měl 8 TB dat a mám stále jako zálohu disku se ZFS. Akorát má drobné divné chování jako třeba na té zmíněné VPS mi při mých subvolumech:

Kód: [Vybrat]

root@web6:~# btrfs subvolume list /
ID 283 gen 299786 top level 5 path @
ID 285 gen 18548 top level 283 path .snapshots/manual-2016-04-14-1623-very_clear_system
ID 286 gen 18549 top level 283 path .snapshots/manual-2016-04-15-1717-installed_and_configured
ID 287 gen 18550 top level 283 path .snapshots/manual-2016-04-19-0206-first_websites_incl_webman
ID 305 gen 250174 top level 283 path .snapshots/manual-2016-05-18-17-36-all_ok
ID 308 gen 252808 top level 283 path .snapshots/manual-2016-05-20-00-50-all_ok
ID 309 gen 284502 top level 283 path .snapshots/manual-2016-05-31-1725-all_ok

Zobrazuje qgroup show dost divná čísla:

Kód: [Vybrat]

root@web6:~# btrfs qgroup show /
qgroupid rfer                 excl
-------- ----                 ----
0/5      16384                18446744073649876992
0/259    1193369600           0
0/260    1463951360           0
0/272    0                    0
0/273    12769861632          10737438720
0/274    18446744065036468224 0
0/275    18446744065125613568 18446744073709539328
0/276    18446744065125924864 18446744073709543424
0/277    18446744065128497152 18446744073709539328
0/278    18446744066230890496 0
0/279    18446744066230161408 18446744073709539328
0/280    18446744066221613056 0
0/281    18446744066252259328 18446744073569497088
0/282    18446744066447921152 0
0/283    4187918336           1588862976
0/284    18446744066164314112 18446744073709408256
0/285    1193598976           176877568
0/286    1464197120           180932608
0/287    2064633856           316268544
0/288    18446744065077616640 18446744073708093440
0/289    18446744065090887680 18446744073708716032
0/290    18446744065051447296 18446744073684271104
0/291    18446744066179928064 18446744073707323392
0/292    18446744066049306624 18446744073692155904
0/293    18446744066344050688 18446744073707667456
0/294    18446744066315300864 210194432
0/295    18446744066311512064 18446744073709023232
0/296    18446744066059468800 21733376
0/297    0                    0
0/301    3958255616           233730048
0/302    4273758208           346615808
0/303    3581575168           751820800
0/304    2835787776           94531584
0/305    2820542464           245665792
0/308    3297984512           294936576
0/309    3950530560           1256808448

Je tu někdo spokojený s Btrfs, kdo ho alespoň 1 rok bez problémů používá na miliony souborů nebo desítky TB?

[mimi]

ano, uplnbe v pohode ..

a ANO prikaz df nema s BTRFS smysl

[mimi]

btw. dobry zdroj informaci o BTRFS je HEronuv blog: https://www.heronovo.cz/category/linux/systemy-souboru/btrfs/

[Mirek Prýmek]

Je to ZFS partitiona šifrovaná přes dm-crypt/LUKS, ale i tak se mi ji podařilo zpřístupnit ve VirtualBoxu pro virtualizované FreeBSD a snad i Oracle Solaris, ale obojí odmítlo tu ZFS partitionu připojit (teď nevím proč přesně).

To je nesmysl, FreeBSD LUKS nepodporuje a Solaris nejspíš taky ne. Ledaže bys tam připojil rozšifrovanou partitionu

[Trubicoid2]

V podstatě btrfs potřebuje čas od času balance, aby se optimalizovalo zabrané místo. Tedy zmenšit rozdíl mezi total a used v

Kód: [Vybrat]

btrfs fi df /
Pak pustíš toto a mělo by se to zlepšit. Eventuálně dát do cronu.

Kód: [Vybrat]

btrfs balance start -musage=99 /
btrfs balance start -dusage=99 /
Předpokládám malý rychlý disk, jinak to bude dlouho trvat a asi je lepší 99 zmenšit.

[dustin]

Ehm, to je ten SMR "zázrak"? No, to se nedivím, že máš potíže s výkonem. Za to ale nemůže souborový systém. 

To je fakt ukrutný čtení... Díky

[Lol Phirae]

To je fakt ukrutný čtení...

No, to je... Než zvyšovat kapacity takhle, tak to fakt radši nic. Nehledě na to, že je každej blbec schopnej triviálně zrealizovat totální DoS na ten systém. 

[Filip Jirsák]

No, to je... Než zvyšovat kapacity takhle, tak to fakt radši nic. Nehledě na to, že je každej blbec schopnej triviálně zrealizovat totální DoS na ten systém. 

Pokud má právo zapisovat do archivního systému každý blbec, je to chyba správce. A pokud někdo použije disky určené pro archivaci pro něco jiného, je to také jeho chyba.

[Mirek Prýmek]

A pokud někdo použije disky určené pro archivaci pro něco jiného, je to také jeho chyba.

Ale no tak. Nejenomže prodejci o tomhle chování neinformují (to bych ještě byl ochotný pochopit - ne omluvit), ale dostatečně srozumitelně to neuvádí ani data sheet výrobce: http://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-ds1834-5c-1508us.pdf - malým písmem, jak na úvěrové smlouvě od lichváře, je tam napsáno, že

you may experience lower performance in these environments

To popisované chování ale není "lower performance" (člověk si pod tím představí třeba o 30% nižší výkon), to je totální nepoužitelnost. Mělo by to tam být napsané palcovým písmem ve žlutém rámečku s velkým trojúhelníkem s vykřičníkem.