Dotaz: Multidisk btrfs - oprava

[kapo]

Zdravím, mám následující problém: Btrfs na 3x3TB disku, data celkem cca 5TB. Před nějakým časem (bohužel nevím kdy) došlo k nějakému problému a 1 disk začal vykazovat divný chování. Dle SMART má aktuálně skoro 6000 špatných sektorů (nečitelný, media error). Nejde o realokované sektory.

Samozřejmě o data přijít nechci :). Zkoušel jsem chybující disk z BTRFS vyrazit (btrfs device delete ...) - to funguje, data to z chybného disku přesouvá pryč, ale jakmile dojde ke špatnému místu, tak skončí s chybou, přes kterou se nedostanu.

Potřeboval bych buď:

- zjistit seznam poškozených souborů

nebo

- donutit disk/btrfs aby nečitelné sektory bral jako plné nul a pokračoval dále - některá data budou v kýblu, ale vzhledem k tomu, že jde o cca 6000 sektorů (3MB?), tak je to celkem zanedbatelný i v těch datech, o která mi jde (fotky, videa)

Máte někdo zkušenosti ? Díky za jakékoliv nasměrování.

---

---

Odpovědi

[Pat1]

A co takhle cele btrfs odmountovat, problemovy disk pomoci ddrescue prekopirovat na jiny a pak znovu namountovat btrfs, tentokrat s dobrym hdd. O data ze spatnych souboru porad prijdes, ale uz by se to nemelo zasekavat na I/O chybach.

[kapo]

To by znamenalo mit dalsi 3TB disk k dispozici. To bohuzel nemam :/

Jinak aktualne zkousim btrfs scrub. Ten do logu vypisuje kazdou chybu vcetne postizenyho souboru, takze to dela vlastne skoro to, co jsem chtel. Postizeny soubory smazu a budu doufat, ze se pak odpojeni ze svazku povede.

[anonym]

BTRFS se neumi obnovit z RAIDu? nebo to mas multidisk bez RAIDu?

zkusil bych pouzivat misto pokusu typu BTRFS neco co funguje spolehlive, treba jeho vzor ZFS

[kapo]

Jako RAID to nemam. Jediny, co je zduplikovany, jsou metadata. Obnovit z RAIDu se btrfs umi. Problem je, ze kdyz ti na disku odejde spousta sektoru (cca 6000), ktery nejsou duplikovany na jinem disku, bude mit problemy jakykoliv FS, i ten ZFS.

Jinak nad ZFS jsem ze zacatku take uvazoval, ale: - na 4GB RAM je to nepouzitelny (ZFS si sezere vsecko a smula) - je to enterprise FS - tam se nepredpoklada, ze by nekdo postupne pridaval jen 1 disk do RAIDu.

[Aleš Kapica]

Pokud to nemáš jako raid, tak máš smůlu. Btrfs data z prstu cucat neumí.

[kapo]

Asi jsem to špatně napsal. Tak ještě jednou:

• je mi jasný, že obsah špatných bloků nezachráním, ale na tom disku je další 1TB dat, která jsou v pořádku
• je to poskládaný ze 3 disků, "RAIDem" jsou chráněna "pouze" metadata
• celý souborový systém připojím

Jde mi o to, jak zjistit, které soubory byly poškozeny vadnými bloky, a jak zachránit zbytek dat za předpokladu, že celková velikost dat se vejde na zbylé 2 3TB disky.

[Andrej]

Btrfs používám od roku 2010 a není to žádný pokus, je to prostě normální filesystém jako každý jiný, jen s vestavěným RAIDem a s checksumy. ZFS funguje skvěle na Illumosu, ale na Linuxu mu Btrfs natrhne prdel co do výkonnosti.

FUD ohledně (údajné, smyšlené, před lety odstraněné) nespolehlivosti nějakého filesystému k řešení problému tazatele příliš nepřispívá.

Děje se jen to, co obvykle dělá Linux při problémech s diskem — nekonečné resetování disku a snaha vadné sektory přečíst. To postihuje všechny filesystémy bez rozdílu. Jednou dojde na timeout, ale obvykle to trvá dlouho.

[kapo]

Takže problém vyřešen následovně:

Napřed připojíme oddíl do nějakého adresáře (např. /mnt/btrfs_root)

Potom provedeme btrfs scrub:

# btrfs scrub start /mnt/btrfs_root

Po jeho skončení se podíváme do /var/log/messages, kde uvidíme mimo jihého i hlášky typu:

Nov 23 09:04:57 micro kernel: btrfs: i/o error at logical 3280823517184 on dev /dev/sdc1, sector 782226816, root 256, inode 260, offset 9871937536, length 4096, links 1 (path: web/virtual_web_server.img)

Tyto hlášky si vyfiltrujeme, ořízneme a získáme seznam všech postižených souborů. Pokud bychom potřebovali některý soubor alespoň zčásti zachránit, použijeme:

# dd if=/mnt/btrfs-root/virtuals/web/virtual_web_server.img of=/mnt/test-disk/backup/virtuals/web/virtual_web_server.img bs=4096 ibs=4096 conv=noerror,sync

Kde bs a ibs nastavíme podle hodnoty parametru "length" z logu.

Po zkopírování všechny postižené soubory smažeme. Následně již můžeme disk vyřadit z btrfs pomocí:

# btrfs device delete /dev/sdc1 /mnt/btrfs_root

, které proběhne již v pořádku.

Výsledek je - zachránili jsme všechna nepoškozená data, filesystém se nerozpadl a reklamační si může užít chybující disk :).

Předpokladem samozřejmě je, že metadata jsou v pořádku (nejlépe použít RAID1, aby byla vždy duplikována), viz:

# btrfs fi df /mnt/btrfs-root/
Data: total=4.97TB, used=3.98TB
System, RAID1: total=32.00MB, used=596.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=144.48GB, used=366.00MB

[Max]

Pěkný, díky.
Zdar Max

[lertimir]

Moc hezké, a jak vidět, btrfs je filesystem, který se dá použít na JBOD i bez RAIDu, s akceptovatelným rizikem ztrát.

[kapo]

Díky, ale rád bych ten optimismus trošku zkrotil. Pokud by totiž disk odešel úplně, tak ten FS nejde připojit vůbec - aktuální kernel na CentOS prostě spadne na kernel panic. Jediným způsobem, jak z něj data dostat, je pak myslím btrfs-restore nebo tak nějak. Ale zase je potřeba další disk, kam data vykopírovat.