Kromě běžného logovacího systému má BTRFS i statistiky příkaz, který sleduje chyby (včetně chyb čtení, zápisu a poškození/kontrolního součtu) na jednotku:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
Takže byste mohli vytvořit jednoduchý root cronjob:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
To zkontroluje počet pozitivních chyb každou hodinu a pošle vám e-mail. Samozřejmě byste takový scénář otestovali (například způsobením poškození nebo odstraněním grep), abyste ověřili, že e-mailové upozornění funguje.
Navíc u pokročilých souborových systémů, jako je BTRFS (které mají kontrolní součet), se často doporučuje naplánovat scrub každých pár týdnů, aby se zjistilo tiché poškození způsobené špatným diskem.
@monthly /sbin/btrfs scrub start -Bq /data
-B možnost ponechá scrub v popředí, takže výsledky uvidíte v e-mailu, který vám cron pošle. Jinak poběží na pozadí a výsledky byste si museli pamatovat ručně, protože by nebyly v e-mailu.
Aktualizovat :Vylepšený grep, jak navrhl Michael Kjörling, díky.
Aktualizace 2 :Další poznámky ke scrubbingu vs. běžné operace čtení (toto neplatí pouze pro BTRFS):
Jak poukázal Ioan, čištění může trvat mnoho hodin, v závislosti na velikosti a typu pole (a dalších faktorech), v některých případech dokonce déle než jeden den. A je to aktivní skenování, nezjistí budoucí chyby – cílem scrubu je najít a opravit chyby na vašich discích v daném okamžiku. Ale stejně jako u jiných systémů RAID se doporučuje naplánovat pravidelné čištění. Je pravda, že typická I/O operace, jako je čtení souboru, kontroluje, zda jsou načtená data skutečně správná. Ale zvažte jednoduché zrcadlení - pokud je první kopie souboru poškozena, možná jednotkou, která brzy zemře, ale druhá kopie, která je správná, je ve skutečnosti čtena BTRFS, pak BTRFS nebude vědět, že došlo k poškození na jednom z pohonů. Je to jednoduše proto, že požadovaná data byla přijata a odpovídají kontrolnímu součtu, který BTRFS uložil pro tento soubor, takže není potřeba, aby BTRFS četl druhou kopii. To znamená, že i když konkrétně čtete soubor, o kterém víte, že je poškozený, na jednom disku, není zaručeno, že toto poškození bude detekováno touto operací čtení.
Nyní předpokládejme, že BTRFS vždy čte pouze z dobrého disku, neproběhne žádný scrub, který by detekoval poškození špatného disku, a pak se pokazí i dobrý disk – výsledkem by byla ztráta dat (alespoň BTRFS by věděl které soubory jsou stále správné a stále vám je umožní číst). Samozřejmě, toto je zjednodušený příklad; ve skutečnosti nebude BTRFS vždy číst z jednoho disku a ignorovat druhý.
Jde ale o to, že pravidelné čištění je důležité, protože najde (a opraví) chyby, které běžné operace čtení nemusí nutně detekovat.
Chybné disky :Vzhledem k tomu, že tato otázka je poměrně populární, rád bych zdůraznil, že toto „řešení pro monitorování“ slouží k odhalování problémů s možná špatnými disky (např. umírající disk způsobující chyby, ale stále dostupný).
Na druhou stranu, pokud je disk náhle pryč (odpojený nebo úplně mrtvý, než aby umřel a produkoval chyby), byl by to vadný disk (ZFS by takový disk označil jako FAULTED). Naneštěstí si BTRFS nemusí uvědomit, že disk je pryč, zatímco je souborový systém připojen, jak je uvedeno v tomto záznamu mailing listu z 09/2015 (je možné, že to bylo opraveno):
Rozdíl je v tom, že máme kód pro detekci, že zařízení není přítomno při připojení, nemáme (zatím) kód, který by detekoval jeho pád na připojený souborový systém. Proč se řádná detekce mizení zařízení nezdá být prioritou, netuším, ale to je jiný problém než chování při připojení.
https://www.mail-archive.com/[email protected]/msg46598.html
Do té doby by v dmesg byly tuny chybových zpráv, takže grepping dmesg nemusí být spolehlivý.
Pro server využívající BTRFS může být nápadem mít vlastní kontrolu (cron job), která odešle upozornění, pokud je alespoň jeden z disků v poli RAID pryč, tj. již není přístupný...
Od btrfs-progs v4.11.1 má statistika možnost --check, která vrátí nenulovou hodnotu, pokud některá z hodnot není nula, čímž se odstraní potřeba regulárního výrazu.
statistiky zařízení -c /
Nespoléhal bych na příkaz stats pro upozornění na chybu, protože tento příkaz nevrací žádnou chybu, pokud disk náhle odejde. Můžete to otestovat odpojením sata kabelu nebo vytažením disku – nedoporučuje se to u důležitého systému souborů.
btrfs device stats /
Po restartu btrfs ukazuje chybějící disk(y), ale to už může být pozdě.
btrfs fi show