Úklid btrfs

16.4.2018 23:59 | Přečteno: 2817× | Linuxové drobty | poslední úprava: 17.4.2018 00:00

Opět drobný zápis pro podpoření paměti. Tentokrát k btrfs systému. V btrfs se velmi vyplatí mít čas od času scrub

Vyvoláme

btrfs scrub start /mount-point-of-btrfs

o běhu a o konci běhu se přesvědčíme

btrfs scrub status /mount-point-of-btrfs

pokud status zobrazi nenulový počet nenapravitelných chyb např.

        total bytes scrubbed: 2.21TiB with 2 errors
        error details: csum=2
        corrected errors: 0, uncorrectable errors: 2, unverified errors: 0

tak je také zajímavé (a potřebné) zjistit v jakých souborech je problém. A pokud jako v mém příkladu jsou na FS 2 chyby error details: csum=2 tak z dmesg zjistíme kde jsou.

dmesg | grep "checksum error at" | tail -2 | cut -d\  -f24- | sed 's/.$//'

případně zapipujeme do souboru > chyby.txt

Co s tím závísí na tom, jak jsou ta data nutné, jsou-li v záloze nebo je-li potřeba obnovy. V každém případě btrfs chybná data nedá. Tedy sektor s chybou součtu skončí s chybou čtení a není dodán. V krajním případě lze použít ddrescue, které nakopiruje soubor bez poškozeného sektoru. To má smysl jen v případě nějakých streamů, kdy data za chybou mají smysl a lze je rozumně interpretovat.        

Komentáře

[Aleš Kapica]

pokud status zobrazi nenulový počet nenapravitelných chyb…

Tak to znamená, že jsem někde něco nedomyslel a měl bych okamžitě uvažovat o nápravě.

[lertimir]

Nevím čím to vzniko. A napravovat nic asi nebudu. Je to 3TB rotační disk, domácí desktop. Na něm je LUKS v a něm je BTRFS. BTRFS zahlásilo chybu. Nicméně pravidelné long testy smartu přímo na disku nikdy nic nezahlásily. A LUKS funguje v pořádku. Na disku byly 2 btrfs chyby ve dvou souborech. Nejsou to kritická data, jsou to vesměs soubory (filmy) z netu, ale chci mít přehled že jsou v pořádku a tak projíždím jak long testy tak scrub. Finálně jsem soubory zkopíroval pomocí ddrescue. Kopírování nahlásilo jeden chybny 4096B velký sektor. Další data na jiných discích nic nehlásily. Chtěl jsem to uklidit a potřeboval jsem najít v jakém jsou souboru. (v podstatě by mi nevadilo ani celý soubor smáznout) Ext4 by mi chybu nenašlo.

[Aleš Kapica]

Vzniklo to tím, že máš pod tím Btfs jen jeden fyzický disk. Takže když ti na něm odejde nějaký sektor, tak jak známo, kde nic není, ani smrt nebere.

Už se to tady nesčetněkrát omílalo, že Btrfs v single módu jedině nad nějakým raidem. Není to sice všemocné, ale lepší než drátem do oka. Optimální minimum je Btrfs v raid1 nad třemi disky.

Zrovna teď nastala modelová situace. Btrfs v raid1 nad 3x 10TB disky. Jeden z nich začal jít do kopru. Protože je ale pole z 90% zaplněné, nezbývá než počkat na nový disk. Až dorazí, nahradí se jím ten vadný a pak se to prohodí. Nicméně až na poslední operaci, kterou je vyjmutí vadného disku z počítače, lze všechno z toho realizovat za běhu, bez toho aniž by bylo nutné přerušit práci. To s jiným typem FS nedáš.

[Petr]

Proc by to neslo s jinym fs? Se zfs menim disky dle potreby bez restartu.

[Aleš Kapica]

Možná je to dnes už jinak, ale svého času, pokud vím, vyžadovalo ZFS aby byly disky pokud možno stejné nebo větší. Do Btrfs raid1 lze zapojit disky různé.

V případě zmíněné modelové situace – kdybych měl k dispozici potřebnou kapacitu alespoň v 1x1TB, 2x2TB a 1x5TB, a v bedně dost místa a SATA portů tak bych na nic nečekal. Jenže ten stroj je stará desktopová šunka, co má jen 4 SATA porty. A dotyčný odmítl upgrade na lepší stroj. Takže si holt musí počkat. Nicméně to půjde. Původně tam chtěl mít opět Ext4. S takovou by už měl ty data dávno v kopru, tak jako už se mu to stalo jednou předtím.

[lertimir]

Pro mne btrfs v single modu nad jedním diskem je pořad lepší než ext4 ve stejné situaci. O chybě se dozvím.

[xkucf03]

Už se to tady nesčetněkrát omílalo, že Btrfs v single módu jedině nad nějakým raidem. Není to sice všemocné, ale lepší než drátem do oka. Optimální minimum je Btrfs v raid1 nad třemi disky.

A teď ještě poraď, jak do toho zakomponovat šifrování. Pokud bude pod RAIDem, tak se vše bude muset šifrovat dvakrát, což zpomalí zápisy. A pokud bude nad, tak Btrfs nemůže těžit z toho, že má dvě kopie dat a pokud je někde chyba, tak je velká pravděpodobnost, že ta druhá kopie je dobrá.

[Want]

Logicky bych očekával šifrování jako transparentní vrstvu nad FS. Tudíž nechápu proč by mělo probíhat 2x. Souborový systém ukládá data, a je mu úplně putna jak vypadají. Max. ho zajímá jak dobře půjdou zkomprimovat.

[xkucf03]

Tzn. použil bys EncFS? Nebo něco jiného nad Btrfs?

Já zatím vždy používal LUKS (a až nad ním LVM a pak FS), protože pak mám jistotu, že je šifrované všechno včetně metadat, swapu nebo dočasných adresářů, takže by nikde nemělo nic unikat.

Asi nejlepší by bylo transparentní šifrování v rámci FS…

[lertimir]

Logicky bych očekával šifrování jako transparentní vrstvu nad FS.

Takže NAD FS. V principu se používají asi 3 hlavní typy šifrování. Na úrovni blokového zařízení. -> šifrují se sektory. LUKS. Na úrovni souborů -> šifrují se soubory. EncFS. Na úrovni kontejneru. -> Ve FS je velký soubor, který obsahuje jiný zašifrovaný FS -> Truecrypt/Veracrypt. Při použití šifrování NAD FS múže utočník vidět vlastnosti jednotlivých souborů (velikost, čas zápisu atd) i když obsah a jméno bude zašifrované. Protože k zašifrovnému FS se dostane vždy a protože tam už to je roseparová na soubory, tak je vidí. Běžně se používá LUKS. Typicky tak, že je RAID v něm je LUKS a v něm je FS. Tím se data vytvořené ve FS zpracují v LUKSu a v Raidu se počítá parita/duplicita již ze zašifrovaných bloků. Tím se šifruje blok jednou. Protože btrfs má RAID v sobě, tak použití LUKSu pod ním musí se musí provést zašifrování na každém blokovém zařízení zvlášť. Jediná rozumná cesta do budoucna je mít uvnitř btrfs také šifrování.

[xkucf03]

Jediná rozumná cesta do budoucna je mít uvnitř btrfs také šifrování.

+1

Neříkám, že EncFS je nepoužitelný, ale IMHO je to vhodné tak na uživatelská data, dokumenty. Jinak použiji raději ten LUKS.

[Want]

Nepřipadáte si krapet paranoidní? Já se spíš setkávám s tím, že lidi chtějí svoje data vydolovat než definitivně pohřbít.

Ano, dovedu si představit situace, kde má šifrování dat smysl, ale rozhodně to není úroveň lokálního fs.

[ehm]

Člověk, který tvrdí, že šifrování disku nedává smysl, jen nemyslel na všechny případy. Daň za šifrování (zprovoznění, nižší výkon, obtížnější mountování disku z jiného systému / livecd) je natolik malá, že se to u běžných počítačů vyplatí snad vždy. Výjimku naopak budou představovat případy, kdy se to nevyplatí.

[Aleš Kapica]

Ano, dovedu si představit situace, kde má šifrování dat smysl, ale rozhodně to není úroveň lokálního fs.

[ehm]

V tom případě ten komentář asi nechápu. Co myslíš tím lokálním FS?

[Aleš Kapica]

Lokální FS je např. zrovna Btrfs.

[lertimir]

Asi jsi chtěl komentovat Wanta a ne ehm. ne?

[Want]

Proč bych komentoval sám sebe? Want je nick když nejsem přihlášený a píšu z mobilu.

Pokud jde o šifrování. Pokud bych chtěl něco šifrovat v rámci lokálního stroje, tak bych využil loop na šifrovaný soubor. V takovém případě ovšem nemá smysl používat Btrfs a sáhnul bych spíš po ext3.

V případě distribuovaného úložiště mi naopak přijde další šifrování jako zbytečný overkill.

[lertimir]

Pokud mám v lokálním desktopu více disků, na kterých mám raid, tak z fyzickou bezpečností jsem na tom skoro stejně jako s jedním diskem. Když mi ho někdo fyzicky vezme tak šifrování ochrání data před jeho čtením. Takže tam data šifruji. Samozřejmě data v servrovně s bezpečnostím režimem na přístup se šifrují málo kdy. Možná jen když je majitel chce uchránit i před přístupem z třípísmených agentůr. Ala protonmail.

[Aleš Kapica]

Pokud mám v lokálním desktopu více disků, na kterých mám raid, tak z fyzickou bezpečností jsem na tom skoro stejně jako s jedním diskem.

Já bych tedy řekl, že o řád lépe. Jeden fyzický disk představuje riziko, jaké bch už dnes podstupovat nechtěl. Proto mám ostatně i v notebooku Btrfs v raid1.

Pokud jde o data. Nepovažuji žádná svoje data za tak citlivá, aby se mi vůbec vyplatilo řešit. Resp. citlivá data třetích stran podle mě nemají na osobním notebooku vůbec co dělat.

Když už bych do podobné situace byl postaven, že bych je přeci jen musel někde udržovat, tak bych to vyřešil — jak jsem naznačil výše – velkým souborem (u kterého bych v případě Btrfs nastavil atribut 'nocow'), který bych připojil přes loop. A na ten bych aplikoval kryptování na úrovni blokového zařízení.

A pak ať se na tom disku hrabe kdo chce. I když z mého pohledu – dávat k reklamaci zařízení s datovým diskem… No. Někdo to tak asi dělá. Záleží na tom, jaký má problém. Já jsem dosud reklamoval pouze chcíplé disky. U strojů to nebylo nikdy zapotřebí. Pokud něco chcíplo, tak to bylo po několika letech provozu a definitivně.

[lertimir]

Ok. Pokud vám Vaše data nestojí za to, přistup k nim řešit, jsme každý na jiné planetě. Mě za to stojí. A pokud to někomu připadá paranoidní budu paranoidní rád.

[Aleš Kapica]

A přesně o tom je svoboda. Každý ať si nakládá se svými daty jak chce.

[lertimir]

Jak souvisí "definitivně pohřbít" s šifrováním? Ke svým zašifrovaným datům mám klíče, nebo kvalitní hesla, a přístup mám zajištěn. Šifrování disků má smysl primárně v situaci, kdy nemohu zabezpečit ochranu fyzického přístupu k systému (diskům) a naopak mohu zabezpečit to, že v případě, kdy systém (disk) nemám plně pod kontrolou, tak je vypnutý. Což je např. šifrování lokálního FS v notebooku nebo stolním počítači. V krizovém případě, že notebook (desktop) někdo ukradne (at již cíleně nebo náhodou) k datům se nemůže dostat.

[xkucf03]

A další dobrý důvod k šifrování jsou reklamace – nikdy nevíš, kdo si bude chtít na vráceném „rozbitém“ disku zkoušet, co vše lze obnovit, a kam tvoje data pak budou putovat. Nikdo ti nezaručí, že reklamovaný disk jen zkontrolují a pak bezpečně zničí.

[Vantomas]

Kdysi jsem někde četl, že fsck od btrfs umí díky checksumům poškozené sektory bruteforce dopočítat a tím takovéhle 4kB bloky zachránit. Existuje tedy na to nějaký nástroj a je to vůbec možné v reálném času bruteforce dopočítat?

[Aleš Kapica]

Nevím. Každopádně, pokud by něco takového bylo součástí kódu, tak je to v něm rovnou implementované. Situace kdy je chyba neopravitelná znamená, že už nepomůže ani svěcená voda.

Pro někoho je asi nezvyklé, že z takového sektoru nelze data jednoduše vydolovat. Je to dáno filozofií přístupu k datům. Z lidského pohledu jsou poškozená data lepší než žádná. Ale jen proto, že jejich následnou analýzu zajistí lidský mozek. Pokud bychom však taková data použili k dalšímu zpracování, tak by mohlo dojít devalvaci i dat původně nepoškozených.

[Petr]

To by jsi hodne dlouho bruteforcoval aby jsi dostal ze 4kB spravny checksum...

[lertimir]

Checksum není kryptografická hash funkce. BTRFS používá Castagnoli implementaci CRC32 (podobně jako ext4 nebo CEPH) označovanou CRC32C a má HW akceleraci v SSE4.2.

[Petr]

To urcite, ale jak chces rychle vygenerovat z niceho neco co ma treba 0x22620404 checksum? Mozna to nevidim, ale porad je to dost prace, nebo ne? Pocitat crc z dat je rychle.

[lertimir]

No primárně CRC není jednosměrná funkce. Pokud by ses jenom trošičku začetl do toho článku na wiki na který jsem dal odkaz, tak víš jednak, že CRC je lineární funkce tedy crc součtu je součet crc sčítanců a jednak jak se počítá, tedy že je to v podstatě zbytek po dělení nějakým polynomem, takže trivíálně uděláš opačný postup, kdy se zbytku a polynomu vypočteš bity, které jsou rozdílné.

[Kkt1]

Super,dekuji za objasneni.

[lertimir]

No to je blbost. Není problém "dopočítat" jakou změnou by se kontrolní součet dostal na správnou hodnotu, problém je v tom, že takovýchto možných změn, které by to provedly, je možné hodně, a je nerozhodnutelné, která je správně. Obecně opravné a detekční kódy pracují tak, že přidáním bitů navíc jsou opravitelné popř. detekovatelné některé druhy chyb. (třeba jeden bit opraví dva bity detekuje na 8 bytů) V závislosti na povaze chyb jsou některé kódy odolnější třeba proti "burst módu" tedy více chyb v blízkém okolí, jiné jsou odolnější proti statisticky náhodném rozdělení chyb. Vždy se musí počítat i s tím, že chyby mohou nastai i v oblasti kontrolních bitů. Nicméně vždy, když chyby přesáhnou možnosti kódu, je to konec. řešeních pak je hodně.

[marbu]

pokud status zobrazi nenulový počet nenapravitelných chyb např.

Ono i když btrfs reportuje, že se mu podařilo chybu opravit, asi bych měl i tak zkontrolovat stav disku, typ chyby, důležitost dat na tom disku a zamyslet se nad tím, zda nechci ten disk vyměnit. Např. pokud by v případě popsaném v blogu byly ty 2 chyby jako na potvoru v btrfs metadatech, které mají ve výchozím nastavení 2 násobnou duplikaci, tak by btrfs vypsal, že nalezl 2 chyby, ale že se mu je podařilo opravit (z té druhé kopie). Na druhou stranu, taková chyba nemusí být vždy způsobená přímo diskem.

[petr]

Dle tohodle blogu mam pocit, ze btrfs sice chybu detekuje, ale neumi ji opravit. Je to tak, nebo tomu jenom nerozumim? Myslel jsem, ze je jaksi self healing jako treba zfs.

[Adolf Kernel]

ZFS (na BSD a Solaris) je ina liga...

[petr]

ano, pouzivam na freebsd, proto se ptam, jestli mimo ku*veni dat ten alfafs je opravdu neumi opravit....

[Aleš Kapica]

Nemel o tom čemu nerozumíš.

[marbu]

Btrfs při čtení každého bloku[1] kontroluje, zda jeho obsah sedí na checksum, který má z dřívějška uložený. Pokud tohle sedí, data jsou předaná dál a čtení z filesystému proběhne. Pokud ale checksum nesedí, podívá se zda není někde uložená další kopie tohoto bloku, a pokud ano, zda u něj sedí checksum. Pokud existuje a jeho checksum sedí, btrfs ten první blok přepíše obsahem toho druhého, a vrátí správná data, tj. čtení normálně proběhne a chyba se opraví. Pokud ale žádný takový další blok neexistuje nebo pokud ten checksum u kopie taky nesedí, není data jak opravit a vrátí se chyba čtení.

[1] Myslí se blok z pohledu filesystému, tj. min. jednotka, s kterou filesystém pracuje.

[petr]

takze to funguje podobne jako u zfs. Jeste jeden dotaz pokud se tomu rozumis - je mozne nastavit u btrfs treba 2 kopie v ramci jednoho poolu? Nebo to musis zrcadlit aby jsi mel vice kopii treba kritickych dat? U zfs pouzivam u kritickych dat vice kopii.

[marbu]

Jo, je možné použít duplikaci dat i u jediného disku (tj. bez použití zrcadlení), zapíná se to přes mkfs.btrfs -d dup .... A jak píšu víše, takto se ve výchozím nastavení ukládají akorát metadata. Viz Btrfs Glossary:

DUP: A form of "RAID" which stores two copies of each piece of data on the same device. This is similar to RAID-1, and protects against block-level errors on the device, but does not provide any guarantees if the device fails. DUP is btrfs default RAID level for metadata on a single, non-rotational device. Regular data can also be assigned the DUP profile.

Ale sám jsem to nikdy nepoužíval, protože btrfs mám jen na ssd disku a tam je to s velkou pravděpodobností stejně k ničemu (smysl by to mělo jen s rotačním diskem), viz: DUP PROFILES ON A SINGLE DEVICE

The mkfs utility will let the user create a filesystem with profiles that write the logical blocks to 2 physical locations. Whether there are really 2 physical copies highly depends on the underlying device type.

For example, a SSD drive can remap the blocks internally to a single copy thus deduplicating them. This negates the purpose of increased redundancy and just wastes filesystem space without the expected level of redundancy.

The wear levelling techniques can also lead to reduced redundancy, even if the device does not do any deduplication. The controllers may put data written in a short timespan into the same physical storage unit (cell, block etc). In case this unit dies, both copies are lost. BTRFS does not add any artificial delay between metadata writes.

[petr]

Dekuji, zajimave. Zfs funguje asi podobne s tim, ze tech kopii mohu definovat vicero v ramci jednoho poolu.

[Aleš Kapica]

Dekuji, zajimave. Zfs funguje asi podobne s tim, ze tech kopii mohu definovat vicero v ramci jednoho poolu.

Ale ne v rámci jednoho blokového zařízení, jak by si mohl někdo myslet.

[Petr]

Jasne. Alesi, jak to funguje treba kdyz mas 3 disky v raid1 a zapnuty ten dup profile? Mas na kazdem disku 2x data, nebo ty data mas 2x v ramci toho raid1?

[Sten]

V Btrfs je RAID stejné nastavení jako single nebo dup (a můžete mít jiný RAID pro data a metadata na stejném poli), takže buď máte raid1 nebo dup. Pokud použijete dup s více disky, jsou všechny bloky v tom poli 2×, ale na rozdíl od raid1 není zaručené, že jsou na různých discích.

[Aleš Kapica]

DUP profile se používá pouze pro metadata. I když by možná na data šel použít taky. Jeho smysl je ovšem pouze v tom, že v případě vadného sektoru neodejde do kopru celý FS.

Je to cca to samé, jako u GPT, které je uloženo na disku také do několika oblastí.

[Nicky726]

Srub (a balance) se vyplatí mít obalený systemd unitou s timery. Pak se to pouští pravidelně a člověk jen občas koukne na logy.

Jinak to vypadá, že v 4.16 jsou nějaké opravy zrychlující scrub nad mnoha pododdíly/snapshoty:

[root@makoto ~]# journalctl -u scrub-btrfs.service 
-- Logs begin at Sun 2018-04-15 19:00:34 CEST, end at Sun 2018-04-29 09:43:13 CEST. --
dub 22 01:00:00 makoto systemd[1]: Starting Scrub BTRFS filesystems...
dub 22 01:00:04 makoto scrub-btrfs.sh[6746]: Running scrub on /mnt/maintenance/makoto_data_btrfs/
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: scrub device /dev/mapper/makoto_data3_luks (id 3) done
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 01:00:04 2018 and finished after 06:19:13
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: scrub device /dev/mapper/makoto_data4_luks (id 4) done
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 01:00:04 2018 and finished after 06:32:22
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 22 07:32:26 makoto scrub-btrfs.sh[6746]: Running scrub on /mnt/maintenance/makoto_ssd_btrfs/
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]: scrub device /dev/vda (id 1) done
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]:         scrub started at Sun Apr 22 07:32:26 2018 and finished after 00:00:15
dub 22 07:32:41 makoto scrub-btrfs.sh[6746]:         total bytes scrubbed: 4.64GiB with 0 errors
dub 22 07:32:42 makoto systemd[1]: Started Scrub BTRFS filesystems.
-- Reboot --
dub 29 01:00:00 makoto systemd[1]: Starting Scrub BTRFS filesystems...
dub 29 01:00:04 makoto scrub-btrfs.sh[18795]: Running scrub on /mnt/maintenance/makoto_data_btrfs/
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: scrub device /dev/mapper/makoto_data3_luks (id 3) done
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 01:00:04 2018 and finished after 02:23:39
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: scrub device /dev/mapper/makoto_data4_luks (id 4) done
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 01:00:04 2018 and finished after 02:27:53
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 1.30TiB with 0 errors
dub 29 03:27:57 makoto scrub-btrfs.sh[18795]: Running scrub on /mnt/maintenance/makoto_ssd_btrfs/
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]: scrub device /dev/vda (id 1) done
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]:         scrub started at Sun Apr 29 03:27:57 2018 and finished after 00:00:15
dub 29 03:28:12 makoto scrub-btrfs.sh[18795]:         total bytes scrubbed: 5.62GiB with 0 errors
dub 29 03:28:12 makoto systemd[1]: Started Scrub BTRFS filesystems.
[root@makoto ~]# uname -a
Linux makoto 4.16.4-1-ARCH #1 SMP PREEMPT Tue Apr 24 13:21:29 UTC 2018 x86_64 GNU/Linux

[xkucf03]

BTW: neumí to cesty k chybným souborům ukládat v nějakém strojově čitelném formátu? V man btrfs-scrub jsem to nenašel. Tzn. je potřeba prohledávat log a tahat to z něj?

[Nicky726]

AFAIK je potřeba tahat z logu. Někde jsem na to, tuším, viděl i nějaký skriptík.

[marbu]

A kam jinam než do logu bys chtěl ty zprávy o chybách ukládat? Ale asi by to chtělo mít líp zdokumentovaný formát té zprávy.

[xkucf03]

Mohl by být dostupný třeba přes /proc jako seznam oddělený nulovým bajtem nebo jako symbolické odkazy na dané soubory. Případně by parametrem příkazu btrfs scrub mohl být soubor, kam se má zapisovat nebo by to šlo prostě na standardní výstup (při použití parametru -B). Případně by si BTRFS mohl do svých metadat ukládat seznam poškozených souborů a pak by sis je příkazem btrfs scrub něco vypsal.

[marbu]

Mohl by být dostupný třeba přes /proc

V /proc asi ne, protože tam informace z konkrétního filesystému nepatří. Ale i kdybychom uvažovali, že to narveme do sysfs informací, co jsou v /sys/fs/btrfs, tak to není zcela dobrý nápad vzhledem k potenciální velikosti a provázanosti takových dat.

Případně by parametrem příkazu btrfs scrub mohl být soubor, kam se má zapisovat nebo by to šlo prostě na standardní výstup (při použití parametru -B).

To by byl trochu problém, protože to běží v kernelu.

Případně by si BTRFS mohl do svých metadat ukládat seznam poškozených souborů a pak by sis je příkazem btrfs scrub něco vypsal.

Tohle už je trochu lepší nápad, ale pořád je to něco co by mohlo udělat víc škody než užitku. Ideálně bych chtěl, aby scrub na filesystém nešahal mimo případy opravy dat.

[Aleš Kapica]

A co si takhle doplnit filtr do logovacího démona a tyhle zprávy odkládat do samostatného logu? To je podle mě standardní postup.

Obsah adresáře /proc se (pokud vím) při restartu zahazuje, takže v případě kdy by chyba vedla ke zhrouzení jádra byste akorát žili v blažené nevědomosti, že vám hnije blokové zařízení pod FS, protože by chyba nebyla ani tam, ani ve standardním logu.

Ale popravdě řečeno. Proč takové opičárny? Když hledám chybu, hledám ji především v syslogu. A stačí mi na to grep a less.

[xkucf03]

Koukám, že už nějaké práce na standardizaci/sjednocení probíhají, dokonce pro různé FS :-)

Btrfs podporuje „drhnutí“ za chodu a ext4 se má časem přidat. Wonga zajímalo, zda by nešlo vytvořit společné rozhraní v uživatelském prostoru. Ted Ts'o řekl, že by se hodilo ujasnit si, co je cílem a jaké jsou požadavky na takový nástroj. Zeptal se, jestli jediná úloha v cronu má drhnout všechny souborové systémy, nebo by ext4 a XFS měly mít samostatné záznamy v crontabu. Cílem by samozřejmě mělo být usnadnit správcům systémů život.

Chris Mason vznesl téma kontrol CRC, který souborové systém provádějí dnes. Když tyto kontroly selhají, každý souborový systém zaznamená svá vlastní oznámení do dmesg. Není v tom žádná konzistence. Wong doporučil, aby Btrfs uživatelskému prostoru vracel chybový stav „souborový systém poškozen“ (filesystem corrupt), jako to dělají ext4 a XFS, ale Mason namítl, že chyby CRC se najdou i jindy než při „drhnutí“ souborového systému.

Zdroj: Jaderné noviny – 17. 5. 2018: „Drhnutí“ a oprava souborového systému XFS za chodu