Oprócz zwykłego systemu rejestrowania, BTRFS posiada polecenie stats , które śledzi błędy (w tym błędy odczytu, zapisu i uszkodzenia / sumy kontrolnej) na dysk:
# 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
Abyś mógł utworzyć prosty cronjob root:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Spowoduje to sprawdzenie dodatniej liczby błędów co godzinę i wysłanie wiadomości e-mail. Oczywiście przetestowałbyś taki scenariusz (na przykład powodując uszkodzenie lub usunięcie grep), aby sprawdzić, czy powiadomienie e-mail działa.
Ponadto w przypadku zaawansowanych systemów plików, takich jak BTRFS (które mają sumę kontrolną), często zaleca się zaplanowanie czyszczenia co kilka tygodni w celu wykrycia cichego uszkodzenia spowodowanego uszkodzeniem dysku.
@monthly /sbin/btrfs scrub start -Bq /data
Ta -Bopcja sprawi, że scrub będzie na pierwszym planie, dzięki czemu zobaczysz wyniki w wiadomości e-mail, którą cron Ci wyśle. W przeciwnym razie będzie działał w tle i trzeba pamiętać o ręcznym sprawdzaniu wyników, ponieważ nie byłoby ich w wiadomości e-mail.
Aktualizacja : Poprawione grep, zgodnie z sugestią Michaela Kjörlinga, dzięki.
Aktualizacja 2 : Dodatkowe uwagi na temat czyszczenia i regularnych operacji odczytu (nie dotyczy to tylko BTRFS):
Jak zauważył Ioan, szorowanie może potrwać wiele godzin, w zależności od wielkości i rodzaju tablicy (i innych czynników), w niektórych przypadkach nawet dłużej niż jeden dzień. Jest to aktywny skan, nie wykrywa on przyszłych błędów - celem peelingu jest znalezienie i naprawienie błędów na twoich dyskach w tym momencie. Jednak, podobnie jak w przypadku innych systemów RAID, zaleca się planowanie okresowych operacji szorowania. Prawdą jest, że typowa operacja we / wy, taka jak odczyt pliku, sprawdza, czy odczytane dane są rzeczywiście poprawne. Ale rozważ proste lustro - jeśli pierwsza kopia pliku jest uszkodzona, być może z powodu dysku, który wkrótce umrze, ale druga kopia, która jest poprawna, jest w rzeczywistości odczytywana przez BTRFS, wtedy BTRFS nie będzie wiedział, że istnieje uszkodzenie na jednym z dysków. Jest tak po prostu dlatego, że otrzymano żądane dane,Oznacza to, że nawet jeśli konkretnie przeczytasz plik, o którym wiesz, że jest uszkodzony na jednym dysku, nie ma gwarancji, że ta operacja odczytu wykryje uszkodzenie.
Załóżmy teraz, że BTRFS zawsze czyta tylko z dobrego dysku, nie jest uruchamiane żadne szorowanie, które wykryłoby uszkodzenie na złym dysku, a następnie dobry dysk również się zepsuje - w wyniku tego nastąpi utrata danych (przynajmniej BTRFS będzie wiedział które pliki są nadal poprawne i nadal pozwolą ci je odczytać). Oczywiście jest to uproszczony przykład; w rzeczywistości BTRFS nie zawsze odczytuje z jednego dysku i ignoruje drugi.
Chodzi jednak o to, że okresowe czyszczenie jest ważne, ponieważ znajdzie (i naprawi) błędy, których normalne operacje odczytu niekoniecznie wykryją.
Uszkodzone dyski : Ponieważ to pytanie jest dość popularne, chciałbym zauważyć, że to „rozwiązanie monitorujące” służy do wykrywania problemów z potencjalnie złymi dyskami (np. Zginający dysk powoduje błędy, ale nadal jest dostępny).
Z drugiej strony, jeśli dysk nagle zniknie (odłączony lub całkowicie martwy, zamiast umierać i powodować błędy), byłby to dysk z błędem (ZFS oznaczałby taki dysk jako AWARIA). Niestety, BTRFS może nie zdawać sobie sprawy z tego, że dysk zniknął podczas montowania systemu plików, jak wskazano w tym wpisie listy mailowej z 09/2015 (możliwe, że został on załatany):
Różnica polega na tym, że mamy kod wykrywający urządzenie nieobecne podczas montowania, nie mamy (jeszcze) kodu wykrywającego upuszczanie go na zamontowanym systemie plików. Dlaczego właściwe wykrywanie zniknięcia urządzenia nie wydaje się priorytetem, nie mam pojęcia, ale jest to kwestia odrębna od zachowania montowania.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
W tym czasie pojawi się mnóstwo komunikatów o błędach, więc grepowanie dmesg może nie być wiarygodne.
W przypadku serwera korzystającego z BTRFS może być pomysł na niestandardowe sprawdzenie (zadanie cron), które wysyła alert, jeśli przynajmniej jeden z dysków w macierzy RAID zniknie, tj. Nie będzie już dostępny ...