Oltre al normale sistema di registrazione, BTRFS dispone di statistiche comando, 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 di root:
[email protected]
@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, testerai uno scenario del genere (ad esempio causando il danneggiamento o rimuovendo il grep) per verificare che la notifica via email funzioni.
Inoltre, con file system avanzati come BTRFS (che hanno il checksum) è spesso consigliato programmare uno scrub ogni due settimane per rilevare la corruzione silenziosa causata da un'unità difettosa.
@monthly /sbin/btrfs scrub start -Bq /data
Il -B l'opzione manterrà lo scrub in primo piano, in modo che tu possa vedere i risultati nell'e-mail che cron ti invia. In caso contrario, verrà eseguito in background e dovresti ricordarti di controllare i risultati manualmente poiché non sarebbero nell'e-mail.
Aggiorna :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 è trovare e correggere gli errori sulle tue 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, corrispondono al checksum che BTRFS ha memorizzato per questo file, quindi non è necessario che BTRFS legga l'altra copia. Ciò significa che anche se leggi specificamente un file che sai essere danneggiato su un'unità, non vi è alcuna garanzia che il danneggiamento venga rilevato da questa operazione di lettura.
Ora, supponiamo che BTRFS legga solo dall'unità buona, non venga eseguito alcuno scrub che rileverebbe il danno sull'unità difettosa, e quindi anche l'unità buona va male - il risultato sarebbe la 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à potenzialmente danneggiate (ad esempio, unità morente che causa errori ma ancora accessibile).
D'altra parte, se un'unità è improvvisamente andata (disconnessa o completamente morta piuttosto che morire e produrre errori), sarebbe un'unità guasta (ZFS contrassegnerebbe tale unità come FAULTED). Sfortunatamente, BTRFS potrebbe non rendersi conto che un'unità è andata mentre il filesystem è montato, come sottolineato in questa voce della mailing list del 09/2015 (è possibile che sia stata corretta):
La differenza è che abbiamo il codice per rilevare che un dispositivo non è presente al montaggio, non abbiamo (ancora) il codice per rilevare che cade 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 questo è un problema separato dal comportamento di montaggio.
https://www.mail-archive.com/[email protected]/msg46598.html
A quel punto ci sarebbero stati tonnellate di messaggi di errore in dmesg, quindi grepping dmesg potrebbe non essere affidabile.
Per un server che utilizza BTRFS, potrebbe essere un'idea avere un controllo personalizzato (cron job) che invii un avviso se almeno una delle unità nell'array RAID è andata, cioè non è più accessibile...
A partire da btrfs-progs v4.11.1 stats ha l'opzione --check che restituirà un valore diverso da zero se uno qualsiasi dei valori non è zero, eliminando la necessità della regex.
statistiche dispositivo -c /
Non farei affidamento sul comando stats per la notifica degli errori, perché questo comando non restituisce alcun errore se un'unità scompare improvvisamente. Puoi testarlo scollegando un cavo sata o estraendo un'unità - non consigliato con un file system importante.
btrfs device stats /
Dopo un riavvio, btrfs mostra le unità mancanti, ma potrebbe essere troppo tardi.
btrfs fi show