Selain sistem pencatatan reguler, BTRFS memang memiliki perintah statistik , yang melacak kesalahan (termasuk kesalahan baca, tulis, dan korupsi / checksum) per drive:
# 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
Jadi Anda bisa membuat cronjob root sederhana:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Ini akan memeriksa jumlah kesalahan positif setiap jam dan mengirimkan Anda email. Jelas, Anda akan menguji skenario seperti itu (misalnya dengan menyebabkan korupsi atau menghapus grep) untuk memverifikasi bahwa pemberitahuan email berfungsi.
Selain itu, dengan filesystem canggih seperti BTRFS (yang memiliki checksumming), sering disarankan untuk menjadwalkan scrub setiap beberapa minggu untuk mendeteksi korupsi diam-diam yang disebabkan oleh drive yang buruk.
@monthly /sbin/btrfs scrub start -Bq /data
The -Bpilihan akan tetap scrub di latar depan, sehingga Anda akan melihat hasilnya dalam cron email mengirimkan Anda. Jika tidak, itu akan berjalan di latar belakang dan Anda harus ingat untuk memeriksa hasilnya secara manual karena mereka tidak akan ada di email.
Pembaruan : Peningkatan grep seperti yang disarankan oleh Michael Kjörling, terima kasih.
Pembaruan 2 : Catatan tambahan tentang menggosok vs operasi baca biasa (ini tidak hanya berlaku untuk BTRFS saja):
Seperti yang ditunjukkan oleh Ioan, scrub dapat memakan waktu berjam-jam, tergantung pada ukuran dan jenis array (dan faktor lainnya), bahkan lebih dari satu hari dalam beberapa kasus. Dan ini adalah pemindaian aktif, tidak akan mendeteksi kesalahan di masa mendatang - tujuan scrub adalah menemukan dan memperbaiki kesalahan pada drive Anda pada saat itu. Tetapi seperti sistem RAID lainnya, disarankan untuk menjadwalkan scrub berkala. Memang benar bahwa operasi i / o biasa, seperti membaca file, tidak memeriksa apakah data yang dibaca benar. Tetapi pertimbangkan mirror sederhana - jika salinan pertama file rusak, mungkin oleh drive yang akan mati, tetapi salinan kedua, yang benar, sebenarnya dibaca oleh BTRFS, maka BTRFS tidak akan tahu bahwa ada korupsi di salah satu drive. Ini hanya karena data yang diminta telah diterima,Ini berarti bahwa bahkan jika Anda secara khusus membaca file yang Anda tahu rusak pada satu drive, tidak ada jaminan bahwa korupsi akan terdeteksi oleh operasi baca ini.
Sekarang, mari kita asumsikan bahwa BTRFS hanya pernah membaca dari drive yang baik, tidak ada scrub dijalankan yang akan mendeteksi kerusakan pada drive yang buruk, dan kemudian drive yang baik menjadi buruk juga - hasilnya akan kehilangan data (setidaknya BTRFS akan tahu file mana yang masih benar dan masih akan memungkinkan Anda untuk membacanya). Tentu saja, ini adalah contoh yang disederhanakan; pada kenyataannya, BTRFS tidak akan selalu membaca dari satu drive dan mengabaikan yang lain.
Tetapi intinya adalah bahwa scrub berkala itu penting karena mereka akan menemukan (dan memperbaiki) kesalahan yang tidak dapat dideteksi oleh operasi baca reguler.
Faulted drive : Karena pertanyaan ini cukup populer, saya ingin menunjukkan bahwa "solusi pemantauan" ini adalah untuk mendeteksi masalah dengan kemungkinan drive yang buruk (mis., Sekarat drive menyebabkan kesalahan tetapi masih dapat diakses).
Di sisi lain, jika drive tiba-tiba hilang (terputus atau benar-benar mati daripada sekarat dan menghasilkan kesalahan), itu akan menjadi drive yang rusak (ZFS akan menandai drive seperti FAULTED). Sayangnya, BTRFS mungkin tidak menyadari bahwa drive hilang ketika sistem file di-mount, seperti yang ditunjukkan dalam entri milis ini dari 09/2015 (mungkin ini telah ditambal):
Perbedaannya adalah bahwa kita memiliki kode untuk mendeteksi perangkat yang tidak ada di mount, kita tidak memiliki kode (belum) untuk mendeteksi itu jatuh pada sistem file yang terpasang. Mengapa deteksi yang tepat untuk perangkat yang hilang tampaknya bukan prioritas, saya tidak tahu, tapi itu masalah terpisah dari perilaku mount.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
Akan ada banyak pesan kesalahan di dmesg saat itu, jadi memahami dmesg mungkin tidak bisa diandalkan.
Untuk server yang menggunakan BTRFS, mungkin gagasan untuk memiliki pemeriksaan khusus (tugas cron) yang mengirimkan peringatan jika setidaknya salah satu drive dalam array RAID hilang, yaitu, tidak dapat diakses lagi ...