Fórum Root.cz
Hlavní témata => Server => Téma založeno: Petr Kratochvíl 05. 06. 2016, 23:15:04
-
Zdravím,
řeším problém na jedné VPS s Debian 8 na Btrfs, které se mountuje těmito údaji v /etc/fstab:
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:
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:
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:
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:
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:
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:
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:
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:
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 (https://btrfs.wiki.kernel.org/index.php/Mount_options#Space_cache_control) :
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:
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/ (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.
-
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.
-
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.
-
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?
-
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/ (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 (http://diit.cz/clanek/recenze-8tb-seagate-archive/zahlceni-disku-do-bezvedomi). ::)
-
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
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 (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ě).
-
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:
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:
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?
-
ano, uplnbe v pohode ..
a ANO prikaz df nema s BTRFS smysl
-
btw. dobry zdroj informaci o BTRFS je HEronuv blog: https://www.heronovo.cz/category/linux/systemy-souboru/btrfs/
-
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 :)
-
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
btrfs fi df /
Pak pustíš toto a mělo by se to zlepšit. Eventuálně dát do cronu.
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.
-
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 (http://diit.cz/clanek/recenze-8tb-seagate-archive/zahlceni-disku-do-bezvedomi). ::)
To je fakt ukrutný čtení... Díky
-
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. :o ::)
-
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. :o ::)
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.
-
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.
-
Ale no tak. Nejenomže prodejci o tomhle chování neinformují
Mně tedy název disku „Archive“ připadá jako klíčová informace. Pokud bych ten disk chtěl použít jinak, než k archivaci, budu si pečlivě zjišťovat, čím je ta řada specifická. Že to používá SMR prodejci informují, že SMR zpomaluje zápis se dočtu i na Wikipedii.
-
Pokud bych ten disk chtěl použít jinak, než k archivaci, budu si pečlivě zjišťovat, čím je ta řada specifická. Že to používá SMR prodejci informují, že SMR zpomaluje zápis se dočtu i na Wikipedii.
A čo si predstavujete pod takým slovom archivácia, Kefalín?
Update June 2nd 2016 : I purchased two of these HDDs and housed them in a NAS. Last December 2015 one died. And yesterday June 1st 2016 the other died. That's a 100% failure ratio and incredibly disappointing. (http://www.guru3d.com/articles_pages/seagate_archive_8tb_hdd_review,13.html)
::) ::) ::)
-
Pokud bych ten disk chtěl použít jinak, než k archivaci, budu si pečlivě zjišťovat, čím je ta řada specifická.
...a v datasheetu se to nedočtu. To je pointa.
-
...a v datasheetu se to nedočtu. To je pointa.
Já tedy v tom vámi odkazovaném datasheetu vidím u všech třech disků SMR – Yes.
-
...a v datasheetu se to nedočtu. To je pointa.
Já tedy v tom vámi odkazovaném datasheetu vidím u všech třech disků SMR – Yes.
Co přesně nechápeš na sdělení, že "you may experience lower performance in these environments" je naprosto klamavé tvrzení?
-
df s btrfs může dávat takovéto výsledky, pokud se hodně projevuje duplikace či RAID:
Velikost = součet velikostí všech jednotek, na kterých je btrfs
Užito = kolik dat je tam reálně nahráno
Volno = kolik dat btrfs odhaduje, že ještě zvládne zapsat
Problém je v tom, že Užito ukazuje, kolik reálných dat tam je, ne kolik to zabírá na jednotkách, tedy nenásobí to koeficienty pro RAID či duplikaci. Pokud metadata používají 1,05 GiB duplikovaně, pak z Velikosti ukousnou 2,10 GiB, ale do Užito zanesou jen 1,05 GiB.
btrfs používám už tři roky. Nemám ho ale na desítkách TiB, „jen“ na 12 TiB (8×2 TiB MD RAID-6). A funguje dobře.
-
U toho bezproblémového užívání po tři roky bych uvítal zmínku o distribuci a kernelu v průběhu těchto tří let. Díky.
-
Pouzivam, gentoo, prubezne aktualizovano, 4x6 v R5 (= ne uplne "stable" konfigurace), krome nesmyslu kolem volnyho mista ... to funguje.
Ono to totiz ukazuje ptakoviny z naprosto libovolnyho uhlu pohledu, ale naprosto nejhorsi je, ze to volny misto je "mozna", pricemz by to melo byt "nejmene". A samo, na R5 nerespektuje konfiguraci, takze pocita jako 24 - ulozeno, coz je hovadina totalni. Je tudiz treba brat v potaz, ze kdyz ukazuje 20 volno, tak ve skutecnosti je to +- 12.
-
Ale no tak. Nejenomže prodejci o tomhle chování neinformují
Mně tedy název disku „Archive“ připadá jako klíčová informace. Pokud bych ten disk chtěl použít jinak, než k archivaci, budu si pečlivě zjišťovat, čím je ta řada specifická. Že to používá SMR prodejci informují, že SMR zpomaluje zápis se dočtu i na Wikipedii.
Archive neznamená, že nemůžu zapisovat náhodně. To že to používá k archivaci, neznamená, že při náhodném zápisu to zkolabuje. Nepleťte si disk s kazetopáskovou jednotkou, kde je sekvenční zápis součástí technologie. Tohle je risk s náhodným přístupem.
-
Jenze ten disk se uvnitr chova jako ta paska ...
-
FreeBSD LUKS nepodporuje a Solaris nejspíš taky ne. Ledaže bys tam připojil rozšifrovanou partitionu :)
Bohužel nepodporuje. Ano, tu partitionu jsem do VirtualBoxu připojoval rozšifrovanou. Zřejmě jediná možnost.
Neexistuje nějaké multiplatformní šifrování napříč Linux, FreeBSD a příp. Solaris (kromě TrueCrypt/VeraCrypt)?
-
Neexistuje nějaké multiplatformní šifrování napříč Linux, FreeBSD a příp. Solaris (kromě TrueCrypt/VeraCrypt)?
Existuje encfs, ale to je spíš na menší množství dat a má nic moc výkon, protože je nad FUSE.
-
Pak pustíš toto a mělo by se to zlepšit. Eventuálně dát do cronu.
btrfs balance start -musage=99 /
btrfs balance start -dusage=99 /
Díky za tip, zkusil jsem se 75 a možná to pomohlo tak o 200 MB. Vypsalo to:
root@web6:~# time btrfs balance start -musage=75 / ; time btrfs balance start -dusage=75 /
Done, had to relocate 5 out of 18 chunks
Done, had to relocate 1 out of 18 chunks
S 99 mám trochu problémy, nejspíš budu muset napřed obětovat nějaký snapshot, aby se uvolnila trocha místa:
ERROR: error during balancing '/' - No space left on device
-
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.
Už to asi chápu. Klasické df do "Used" z nějakého důvodu nezapočítává duplikovaná metadata, která u mne dle "btrfs fi df" zabírají 940 MB:
root@web6:~# btrfs filesystem df /
Data, single: total=9.95GiB, used=9.72GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.35GiB, used=940.31MiB
GlobalReserve, single: total=240.00MiB, used=0.00B
A jelikož záhadně chybějící volné místo dle df je cca 720 MB, tak by to mohla být nezapočítaná metadata.
root@web6:~# df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 13619200 12367364 531612 96% /
Jenže 940 MB a 720 MB jsou trochu odlišné hodnoty a navíc to nevysvětluje tu neopravitelnou chybu z výpisu "btrfs check" a zmatená čísla ve výpisu "btrfs qgroup show".
btw: Tu ZFS partitionu na tom 8 TB SMR disku jsem včera opět zkusil připojit přes zfsonlinux read-write. Asi tak 15 hodin se prováděl příkaz "zpool import" a zuřivě to pracovalo a pak práce disku přestala a stroj přestal reagovat. Do syslogu se problém, ať už je jakýkoliv, nestihne zaznamenat. Včera jsem to zkusil ve virtuálce, ale totéž to dělá i nativně. Asi opravdu jedině data evakuovat na ne-SMR disk. Proto řeším, zda na ZFS nebo zda je již Btrfs dostatečně zralé.
-
tak zmatena cisla dela jenom stary kernel, ne? ja bych btrfs radeji provozoval na 4.6 nez na kernelu rady 3...
navic na zacatku jsi mel metadata jak DUP tak single, to neni asi dobre
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
vono myslim mkfs.btrfs detekuje SSD, nebo HDD a na SSD dela system/metadata single a na HDD DUP, toto jako by bylo v polovine convertu nebo co
asi bych udelal, nebo mkfst.btrfs znova
btrfs balance start -mconvert=single /
-
tak zmatena cisla dela jenom stary kernel, ne? ja bych btrfs radeji provozoval na 4.6 nez na kernelu rady 3...
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
root@web6:~# btrfs subvolume list /
ID 283 gen 303818 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 308 gen 303619 top level 283 path .snapshots/manual-2016-05-20-00-50-all_ok
ID 309 gen 303619 top level 283 path .snapshots/manual-2016-05-31-1725-all_ok
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 3836088320 1323204608
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 18446744070282821632 0
0/308 3289006080 958746624
0/309 3950317568 1336872960
navic na zacatku jsi mel metadata jak DUP tak single, to neni asi dobre
vono myslim mkfs.btrfs detekuje SSD, nebo HDD a na SSD dela system/metadata single a na HDD DUP, toto jako by bylo v polovine convertu nebo co
asi bych udelal, nebo mkfst.btrfs znova
btrfs balance start -mconvert=single /
Ok, díky, zkusím.
-
U toho bezproblémového užívání po tři roky bych uvítal zmínku o distribuci a kernelu v průběhu těchto tří let. Díky.
Debian 7. Jádro je 3.16 (plus debianní bezpečnostní backporty), v záznamech jsem jej našel i před dvěma lety, jestli tam bylo od počátku, to už nevím (ale při pohledu do debianního seznamu balíčků tam pravděpodobně bylo 3.12).
Už to asi chápu. Klasické df do "Used" z nějakého důvodu nezapočítává duplikovaná metadata, která u mne dle "btrfs fi df" zabírají 940 MB:
Ona je otázka, co by to Used mělo vlastně znamenat. Ve starších jádrech btrfs uvádí, kolik dat tam skutečně je, tedy kolik bude potřeba uložit při archivaci pomocí btrfs-send. V novějších jádrech to uvádí, kolik dat to zabírá na úložišti.
-
Pro info: Zkusil jsem "btrfs balance" s různými parametry. První dvě varianty po chvíli napsaly "No space left on device", kdežto poslední se dokončila bez problémů:
time btrfs balance start / ; btrfs balance start -dusage=100 / ; btrfs balance start -dusage=99 /
Také jsem před tím Metadata zesinglil, což by prakticky nemělo vadit, jelikož se jedná o SSD VPS, snad leda v případě zálohování binární kopií na klasický mechanický disk:
btrfs balance start -mconvert=single -v -f /
A výsledek?
root@web6:~# btrfs fi df /
Data, single: total=10.00GiB, used=9.07GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.25GiB, used=754.52MiB
GlobalReserve, single: total=224.00MiB, used=0.00B
root@web6:~# df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 13619200 10509080 2767944 80% /
13619200 = 10509080 + 2767944 + "zmizelých" 342176 kB (dříve 998336 kB)
Ok, df nevěřit. V tom případě je důležitější jiný údaj z toho řádku, na který imho aplikace a systém hledí při zápisu do souborů: Available: 2767944 kB
Výše zmíněné Btrfs příkazy pomohly. Bohužel nevím jak moc přesně, protože jsem před balance a mconvert=single něco ručně smazal, ale smazal jsem rozhodně méně než uvolněných více než 2 GB. Brzy ještě zkusím zda "btrfs check" stále píše chybu.
Každopádně teď už vím co v takové situaci příště dělat. Děkuji všem moc za rady.
-
Ještě máš moc metadat, ve výpisu btrfs fi df total proti used, tak pusť ještě -musage=99
100 by to jako parametr ani nemělo brát myslím
-
Pěkný článek o SMR, kde je vysvětleno, proč se to tak chová http://diit.cz/clanek/recenze-8tb-seagate-archive (http://diit.cz/clanek/recenze-8tb-seagate-archive)
-
Tak se objevil ještě jeden problém, který může s tím vším souviset.
Po tom opakovaném spouštění "btrfs mconvert" a "btrfs balance" s různými parametry jsem si řekl, že na závěr vytvořím read-only snapshot. Jenže ouha:
root@web6:/# btrfs subvolume snapshot -r /.snapshots/manual-2016-06-09-2136-all_ok /
ERROR: error accessing '/.snapshots/manual-2016-06-09-2136-all_ok'
Tušíte někdo jak to vyřešit? Z dob před řešením volného místa mám vytvořené a dostupné 4 snapshoty, ale nový prostě nevytvořím, i když používám stejný způsob. Chybu "error accessing" znám v souvislosti s pokusem o smazání snapshotu vytvořeného utilitou apt-btrfs-snapshot, kterou jsem myslím dříve používal, ale tu jsem jednak odinstaloval a pak se nyní jedná o vytvoření a ne smazání snapshotu.
Volné místo by být mělo, navíc by ho nemělo být moc potřeba:
root@web6:/# btrfs fi df /
Data, single: total=9.00GiB, used=8.73GiB
System, single: total=64.00MiB, used=16.00KiB
Metadata, single: total=1.50GiB, used=759.33MiB
GlobalReserve, single: total=224.00MiB, used=2.59MiB
root@web6:/# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 13G 9.7G 2.7G 79% /
-
Asi mi něco uniká, ale co má ksakru za smysl v dnešní době řešit 200MB místa na disku za cenu totálního rozmrdání filesystému (jehož defaultní nastavení jsou asi defaultní proto, že to dává nějaký smysl)?
::) ::) ::)
-
Asi mi něco uniká, ale co má ksakru za smysl v dnešní době řešit 200MB místa na disku za cenu totálního rozmrdání filesystému (jehož defaultní nastavení jsou asi defaultní proto, že to dává nějaký smysl)?
::) ::) ::)
Odpovím citáty:
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.
Předem děkuji za jakékoliv konstruktivní rady.
navic na zacatku jsi mel metadata jak DUP tak single, to neni asi dobre
-
Jenže ouha:
root@web6:/# btrfs subvolume snapshot -r /.snapshots/manual-2016-06-09-2136-all_ok /
ERROR: error accessing '/.snapshots/manual-2016-06-09-2136-all_ok'
Jsem už z toho všeho nějak zmatený, moje chyba.
Tímto se omlouvám čtenářům a s radostí i souborovému systému Btrfs a děkuji za pomoc s vyřešením problémů. Najdete níže rozdíl v parametrech oproti kódu v citátu výše? ;-)
root@web6:/# btrfs subvolume snapshot -r / /.snapshots/manual-2016-06-09-2136-all_ok
Create a readonly snapshot of '/' in '/.snapshots/manual-2016-06-09-2136-all_ok'
-
ked som sa este venoval btfrs tak pisali na tych internetoch ze iba btrfs samotne rozumie tomu kolko miesta vlastne ma:
$ sudo btrfs fi show
Label: none uuid: 12345678-1234-5678-1234-1234567890ab
Total devices 2 FS bytes used 304.48GB
devid 1 size 427.24GB used 197.01GB path /dev/sda1
devid 2 size 465.76GB used 197.01GB path /dev/sdc1
https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_free_space_do_I_have.3F