btrfs raid1 balance - no space on device - wtf? (diskuse)

[Heron]

Skutocne je nutne na zmirrorovanie dat z jedneho disku na druhy mat volnych ~50% disku?

Není. Alokační grupa BTRFS je 1GB, to znamená, že pokud na tom disku bylo 7GB dat, tak už tam nemuselo být dostatek místa pro přesuny 1GB balíků dat.

BTRFS je stavěno na velký disky (tuhle facebook řešil rychlost mazání xTB souborů), zkoušet to na 8GB není ten nejlepší scénář.

Já mám 4+3TB disky v BTRFS raid1 a výměna disků a konverze (raid 1 - raid10) je no problémo. Při 80% zaplnění.

[Hulk]

nemas odkaz na ten FB a problem mazania TB dat ?

[Heron]

Např zde:

https://lkml.org/lkml/2015/4/23/593

[msk]

Myslel som si, ze to bude tou malou velkostou diskov. Musim povedat, ze som sa k vyskusaniu inspiroval Tvojim blogom.

Mam teda rovno teoreticky dotaz k veci, ktora mi neni uplne jasna.

Mam raid-1 pole zo sda,sdb,sdc,sdd. Umre mi sdc, ale nemam ziaden dalsi volny sata port, takze musim vymenit sdc za nove sdc. Ide to?

Diky

[Heron]

Mam raid-1 pole zo sda,sdb,sdc,sdd. Umre mi sdc, ale nemam ziaden dalsi volny sata port, takze musim vymenit sdc za nove sdc. Ide to?

Jde. Prostě vytáhneš vadný sdc, uděláš btrfs device delete missing (umount, mount -o degraded, delete ... - pokud už to někdo neopravil) a potom device add , balance a je to. Taky mám plný sata sloty a 3TB seagaty odcházej (zatím teda jen dva). Jen je blbý, že se to nedá udělat za běhu a musí tam být ten umount, mount -o degraded. (Alespoň na 3.16, na 4.2 jsem to zatím netestoval.)

[msk]

Pokus nad loop-om:

        Total devices 3 FS bytes used 2.00GiB
        devid    1 size 8.00GiB used 1.28GiB path /dev/loop1
        devid    2 size 8.00GiB used 2.28GiB path /dev/loop2
        devid    3 size 8.00GiB used 3.00GiB path /dev/loop3

warning, device 2 is missing
warning devid 2 not found already

root@debian:~/tmp# btrfs d delete missing mnt/

... a zasek, nic sa nedeje, ziadna io aktivita, proste nic.

[Heron]

Ten výpis je nějaký divný. Píše dev 2 missing, ale dev 2 ve výpisu je.

Ráno se na to zkusím u ranní kávy mrknout, toto si obvykle zkouším ve virtuálce, s loopy jsem nikdy příliš nepracoval (jen readonly mount iso souboru). Teď jsem v rychlosti došel k tomuto:

losetup -d /dev/loop2

losetup -a
/dev/loop1: [0209]:257 (/home/test/disk1)
/dev/loop3: [0209]:259 (/home/test/disk3)

loop2 chybí, což je správně. Jenže:

mount /dev/loop1 /mnt/btest

Neprojde, což se dá očekávat. Potom:

mount /dev/loop1 /mnt/btest -o degraded

btrfs fi show /mnt/btest

Total devices 2 FS bytes used 2.93GiB
devid    1 size 100.00GiB used 4.03GiB path /dev/loop1
devid    2 size 100.00GiB used 4.03GiB path /dev/loop2

Kde se tam vzala /dev/loop2?

Nevím, s loopy nepracuji, nevím, jak je vidí kernel. Userspace programy (fdisk) vidí loop1 (správně upozorní na btrfs signaturu), loop3 jako čisté blokové zařízení (ten jsem ještě nepoužil), ale na loop2 nemůže (správně) přistupovat. Kernel ovladač btrfs jej však vidí. Důvod neznám.

Toto se u reálného zařízení nestalo, to tam prostě bezpečně není. Takže to vyzkoušej když tak ve virtuálce (vypnout, odebrat zařízení, zapnout), tady se to evidentně hádá s loopem.

[msk]

Tak pokus priamo s diskami vo virtuale:

Total devices 3 FS bytes used 2.93GiB
        devid    1 size 8.00GiB used 1.28GiB path /dev/sdb
        devid    3 size 8.00GiB used 3.00GiB path /dev/sdd
        *** Some devices missing
warning, device 2 is missing

b d delete missing mnt/

... zasek, nic sa nedeje. Mam ten pocit, ze tomuto (zjavne stale experimentalnemu) fs svoje data nezverim, aj ked featury ma dost lakaju ...

[Heron]

Počáteční stav, tři disky na hraní:

/dev/sdb  /dev/sdc  /dev/sdd

Vytvoříme btrfs single

mkfs.btrfs /dev/sdb

mount /dev/sdb /mnt/test

Dáme tam pár dat:

for i in `seq 1 30`; do dd if=/dev/zero of=file$i bs=1M count=100; done

Jak jsme na tom:

 btrfs fi show

Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 1 FS bytes used 2.84GiB
        devid    1 size 100.00GiB used 5.04GiB path /dev/sdb

Přidáme disk a uděláme raid1:

 btrfs device add /dev/sdc /mnt/test


Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 2 FS bytes used 2.93GiB
        devid    1 size 100.00GiB used 5.04GiB path /dev/sdb
        devid    2 size 100.00GiB used 0.00B path /dev/sdc

 btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt/test

Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 2 FS bytes used 2.93GiB
        devid    1 size 100.00GiB used 6.03GiB path /dev/sdb
        devid    2 size 100.00GiB used 6.03GiB path /dev/sdc

Potud vše ok. Vyrveme disk sdc, původní sdd se nám přečísluje na sdc:

ls /dev/sd*
/dev/sdb  /dev/sdc

Zkusíme to namountovat:

mount /dev/sdb /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Nejde, máme málo disků, takže degraded:

root@debian:~# mount /dev/sdb /mnt/test -o degraded

Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 2 FS bytes used 2.93GiB
        devid    1 size 100.00GiB used 6.03GiB path /dev/sdb
        *** Some devices missing

Správně, nějaké zařízení chybí. Takže odstraníme missing:

 btrfs device delete missing /mnt/test
ERROR: error removing the device 'missing' - unable to go below two devices on raid1

Správně nejde, nemáme disky na požadovaný raid level. Strčíme tam nový disk:

btrfs device add /dev/sdc /mnt/test


 btrfs device delete missing /mnt/test

Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 2 FS bytes used 2.93GiB
        devid    1 size 100.00GiB used 4.03GiB path /dev/sdb
        devid    3 size 100.00GiB used 4.03GiB path /dev/sdc

Přemountíme do normálního režimu:

umount /mnt/test
mount /dev/sdb /mnt/test

A vše je ok:

Label: none  uuid: 01396906-eb6f-43d5-9b38-59bca8363b6e
        Total devices 2 FS bytes used 2.93GiB
        devid    1 size 100.00GiB used 4.03GiB path /dev/sdb
        devid    3 size 100.00GiB used 4.03GiB path /dev/sdc

[Heron]

Otestováno teď na Debianu 8 (stable), jadérko 3.16, btrfs 3.17.

[msk]

Hm, tak si sypem popol na hlavu, upgradol som na 3.16 a uz je to ok. Budem to teda nejak viac testovat. A ma podla Teba zmysel do debianu skusat nejak skompilovat vanilku 4.1.6, alebo v klude zostat na 3.16?

[Heron]

Nevím, já mám btrfs 5+ let, začínal jsem kdysi na 2.6.18 CentOS5 (kam byl backportován z 2.6.32 a kde nefungovalo správně multidevice, což je za těch 5 let jediná nepříjemná zkušenost). Od té doby Debian 6 - 7 - 8, (aktuálně mám někde deb stable a jinde testing) a všude to ty roky funguje bez problémů (až na wtf moment s nutností mount -o degraded).

Od 3.10 je označen jako stable.

Takže já nejsem ten správný člověk, co se týče verzí, mě to jede všude. A než brát vanilkový kernel a kompilovat si btrfs-tools, tak raději stable distro.

[msk]

Wow tak to cumim. Zobral si mi otazku z ust - chcel som sa opytat, ci si za tie roky, co ten fs pouzivas, narazil na nejaky problem so stratou dat, zjavne teda nie. Dam tomu par dni testovania pod virtualboxom a potom sa uvidi. Diky.

[Heron]

Ztrátu dat ne (krom toho 2.6.18, ale tam byla kravina to vůbec zkoušet, backportovaná devel verze o 14 verzí zpět).

Jednou jsem dělal nějakou šílenost s miliony souborů a pro zábavu jsem dělal po každém kroku snapshot té subvolume. Po několika desítkách snapshotů nastala chyba nedostatek místa na disku (ENOSPC), přičemž místa bylo dost. "Problém" byl, že used bylo 100% a btrfs neměl místo pro metadata (která měla skoro 100GB). No stačilo balance -dused=0 (což je velmi rychlé) a místa bylo dost a mohlo se v tom šílenství vesele pokračovat (potom byla sranda to mazat ).

Tím chci říct, že v případě nestandardní situace není třeba panikařit a hned sahat po záloze. Ze spousty situací se lze jednoduše dostat.

Trochu mi to připomíná postgresql před zavedením autovacuum (a to není zase tak dlouho), kde se vacuum (full) analyze volalo z cronu, a když nevolalo, tak db postupně vyplnila veškerý pozorovatelný vesmír. Dneska už to nikdo neřeší, autovacuum běží by default. Stejně tak časem jistě bude proces pro uvolňování prázdných bloků v btrfs.

[kapo]

Jaké úrovně RAIDu u btrfs používáš? Jak se btrfs staví k situaci, kdy z disku nejde přečíst sektor (a disk jej, dokud do něj nezapíšeš, nepřealokuje)? Já se potácím s problémy v tomto případě, kdy to musím "ručně" opravovat, protože u RAID5 to btrfs sám prostě nezregeneruje, ikdyž by měl mít data k dispozici z ostatních disků. Používám openSUSE 13.2.

Jinak pro autora zápisku - RED edice WD disků se při chybě sektoru zas tolik nesnaží to správně přečíst a rychleji vyhodí chybu, než desktopová verze. Už jsem takhle 1 3T disk "votočil" s jejich německou filiálkou.

[Heron]

single, raid0 (nad hw raid1), raid1 a experimentálně raid10 (ale s tím se špatně manipuluje, tam už to chce pro pohodlnou práci hodně disků). Asi 3x jsem měnil mezi raid1 a raid10, protože jsem potřeboval snížit počet disků pod 4.

Raid5/6 byla "stabilizovaná" teprve ve verzi 3.19, tomu bych ještě nějaký ten pátek na vychytání chyb nechal.

Jak se btrfs staví k situaci, kdy z disku nejde přečíst sektor (a disk jej, dokud do něj nezapíšeš, nepřealokuje)?

Teoreticky by měl data přečíst z jiného disku. Bohužel, desktoptové disky čtou tak dlouho až přečtou a s tím btrfs nic neudělá. Jak správně píšeš, raid disky mají TLER a chybu vrátí rozumně rychle.

[Jendа]

Nevím, já mám btrfs 5+ let, začínal jsem kdysi na 2.6.18 CentOS5

Tak to jsi dobrej střelec :). Já jsem se odvážil teprve nedávno a zatím dobré, jenom když to něco dělá (třeba teď ten balance), tak jsou v IO na systému několikasekundové lagy (např. :w ve vimu zřetelně trvá, i když edituju soubor na jiné partition stejného disku). To se při resyncu MD nedělo.

WTF moment byl, když jsem zjistil, že mi -o compress=zlib nekomprimuje accesslogy. Nechápu. S compress-force to funguje.

[Heron]

Tak to jsi dobrej střelec :).

Tento článek je z roku 2011, pochopitelně jsem s tím začal před psaním. Trochu mě mrzí, že se tady na abíčku vytratila paměť a lidi (i stálice na portálu) k sobě vzájemně přistupují jako tabula rasa. Ale tak zapomenout může každý. Taky zapomínám.

[Jendа]

Tak je rozdíl zkoušet a reálně nasadit.

[Heron]

No to je fakt. Já píšu o tom, co sám používám.

[Jendа]

Já přes teď migroval zděděný server z CentOS5 na Jessie, dal jsem tam jádro 4.1 z backportů. Teď běží btrfs balance na raid1, jsou to dva 2TB disky, je tam 1.4 TB dat a v pohodě (za asi hodinu je 200 GB hotovo).

[Good]

To je jisté. 192.168.l.l 192.168.0.1

[Heron]

A je nutne, aby na disku, ktory ma 8GB a 4.4GB suborov bolo "used 6.33GiB"?

To není used ve smysl zabraného místa soubory, ale velikost fs na daném blokovém zařízení. Když pustíš balance -dusage=0, tak projde "prázdné" bloky a toto číslo se sníží. Po nějaké době provozu bude ve výpisu fi show used stejně velký jako je blokové zařízení pod ním. Opět, pomocí balance, nebo třeba resize (btrfs umí za běhu zmenšit použité místo na daném blokovém zařízení a toto zařízení můžeš potom zmenšit (třeba lvreduce, pokud je to nad lvm)), můžeš toto číslo snížit. Ale není k tomu důvod.

[Hanna]

Thanks for sharing it. I found this Information very interesting and informative! Keep sharing 192.168.1.1 192.168.1.1 192.168.1.1 192.168.1.1

[KentPeacock]

Súhlasím, tak už tam nemuselo být dostatek místa pro přesuny 1GB balíků dat. 192.168.l.l