Oltre al normale sistema di registrazione, BTRFS ha un comando stats , che tiene traccia degli errori (inclusi errori di lettura, scrittura e corruzione / checksum) per unità:
# 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
Quindi potresti creare un semplice cronjob root:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Questo verificherà il numero di errori positivi ogni ora e ti invierà un'e-mail. Ovviamente, verificheresti un tale scenario (ad esempio causando corruzione o rimuovendo il grep) per verificare che la notifica e-mail funzioni.
Inoltre, con filesystem avanzati come BTRFS (con checksum) è spesso consigliabile pianificare uno scrub ogni paio di settimane per rilevare la corruzione silenziosa causata da un'unità guasta.
@monthly /sbin/btrfs scrub start -Bq /data
L' -Bopzione manterrà lo scrub in primo piano, in modo da vedere i risultati nell'e-mail cron che ti invia. Altrimenti, verrà eseguito in background e dovresti ricordare di controllare i risultati manualmente poiché non sarebbero presenti nell'email.
Aggiornamento : grep migliorato come suggerito da Michael Kjörling, grazie.
Aggiornamento 2 : note aggiuntive sullo scrubbing rispetto alle normali operazioni di lettura (questo non si applica solo a BTRFS):
Come sottolineato da Ioan, uno scrub può richiedere molte ore, a seconda delle dimensioni e del tipo di array (e di altri fattori), in alcuni casi anche più di un giorno. Ed è una scansione attiva, non rileverà errori futuri - l'obiettivo di uno scrub è quello di trovare e correggere gli errori sulle unità in quel momento. Ma come con altri sistemi RAID, si consiglia di programmare scrub periodici. È vero che una tipica operazione di I / O, come la lettura di un file, verifica se i dati letti sono effettivamente corretti. Ma considera un semplice mirror: se la prima copia del file è danneggiata, forse da un'unità che sta per morire, ma la seconda copia, che è corretta, viene effettivamente letta da BTRFS, allora BTRFS non saprà che c'è corruzione su una delle unità. Questo semplicemente perché i dati richiesti sono stati ricevuti,Ciò significa che anche se si legge specificamente un file che si ritiene sia danneggiato su un'unità, non è possibile garantire che il danneggiamento venga rilevato da questa operazione di lettura.
Ora, supponiamo che BTRFS legga sempre e solo dal buon disco, non venga eseguito scrub che rilevi il danno sul disco cattivo e quindi anche il buon disco vada male - il risultato sarebbe una perdita di dati (almeno BTRFS lo saprebbe quali file sono ancora corretti e ti permetteranno comunque di leggerli). Naturalmente, questo è un esempio semplificato; in realtà, BTRFS non leggerà sempre da un'unità e ignorerà l'altra.
Ma il punto è che gli scrub periodici sono importanti perché troveranno (e correggeranno) errori che le normali operazioni di lettura non rileveranno necessariamente.
Unità guaste : poiché questa domanda è piuttosto popolare, vorrei sottolineare che questa "soluzione di monitoraggio" serve a rilevare problemi con unità probabilmente guaste (ad esempio, morire unità causando errori ma ancora accessibili).
D'altra parte, se un'unità è improvvisamente scomparsa (scollegata o completamente morta anziché morire e produrre errori), sarebbe un'unità guasta (ZFS contrassegnerebbe un'unità come GUASTO). Sfortunatamente, BTRFS potrebbe non rendersi conto che un'unità è sparita mentre il filesystem è montato, come sottolineato in questa voce della mailing list dal 09/2015 (è possibile che questo sia stato corretto):
La differenza è che abbiamo il codice per rilevare un dispositivo non presente al mount, non abbiamo (ancora) il codice per rilevarlo cadere su un filesystem montato. Perché avere un rilevamento adeguato per la scomparsa di un dispositivo non sembra essere una priorità, non ne ho idea, ma si tratta di un problema separato dal comportamento di montaggio.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
A quel tempo ci sarebbero stati un sacco di messaggi di errore in dmesg, quindi dmesg grepping potrebbe non essere affidabile.
Per un server che utilizza BTRFS, potrebbe essere un'idea avere un controllo personalizzato (cron job) che invia un avviso se almeno una delle unità nell'array RAID è sparita, cioè non è più accessibile ...