Selain sistem logging reguler, BTRFS juga memiliki statistik perintah, 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:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Ini akan memeriksa jumlah kesalahan positif setiap jam dan mengirimkan email kepada Anda. Jelas, Anda akan menguji skenario seperti itu (misalnya dengan menyebabkan kerusakan atau menghapus grep) untuk memverifikasi bahwa pemberitahuan email berfungsi.
Selain itu, dengan sistem file canggih seperti BTRFS (yang memiliki checksumming), sering kali 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
-B opsi akan menyimpan scrub di latar depan, sehingga Anda akan melihat hasilnya di email yang dikirimkan cron kepada Anda. Jika tidak, ini akan berjalan di latar belakang dan Anda harus ingat untuk memeriksa hasilnya secara manual karena tidak akan ada di email.
Perbarui :Peningkatan grep seperti yang disarankan oleh Michael Kjörling, terima kasih.
Perbarui 2 :Catatan tambahan tentang operasi scrubbing vs. operasi baca biasa (ini tidak hanya berlaku untuk BTRFS saja):
Seperti yang ditunjukkan oleh Ioan, scrub bisa memakan waktu berjam-jam, tergantung pada ukuran dan jenis larik (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 untuk menemukan dan memperbaiki kesalahan pada drive Anda pada saat itu. Namun seperti sistem RAID lainnya, disarankan untuk menjadwalkan scrub berkala. Memang benar bahwa operasi i/o biasa, seperti membaca file, memeriksa apakah data yang dibaca benar. Tetapi pertimbangkan cermin sederhana - jika salinan pertama file rusak, mungkin oleh drive yang hampir 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, cocok dengan checksum yang disimpan BTRFS untuk file ini, jadi BTRFS tidak perlu membaca salinan lainnya. Ini berarti bahwa meskipun Anda secara khusus membaca file yang Anda tahu rusak di satu drive, tidak ada jaminan bahwa kerusakan tersebut akan terdeteksi oleh operasi baca ini.
Sekarang, mari kita asumsikan bahwa BTRFS hanya membaca dari drive yang baik, tidak ada scrub yang dijalankan yang akan mendeteksi kerusakan pada drive yang buruk, dan kemudian drive yang baik juga menjadi buruk - hasilnya adalah kehilangan data (setidaknya BTRFS akan tahu file mana yang masih benar dan masih memungkinkan Anda untuk membacanya). Tentu saja, ini adalah contoh yang disederhanakan; pada kenyataannya, BTRFS tidak selalu membaca dari satu drive dan mengabaikan yang lain.
Namun intinya adalah scrub berkala itu penting karena mereka akan menemukan (dan memperbaiki) kesalahan yang tidak perlu dideteksi oleh operasi baca reguler.
Drive bermasalah :Karena pertanyaan ini cukup populer, saya ingin menunjukkan bahwa "solusi pemantauan" ini adalah untuk mendeteksi masalah dengan kemungkinan drive yang buruk (mis., drive sekarat yang menyebabkan kesalahan tetapi masih dapat diakses).
Di sisi lain, jika drive tiba-tiba hilang (terputus atau benar-benar mati daripada mati dan menghasilkan kesalahan), itu akan menjadi drive yang rusak (ZFS akan menandai drive tersebut sebagai FAULTED). Sayangnya, BTRFS mungkin tidak menyadari bahwa drive hilang saat sistem file dipasang, seperti yang ditunjukkan dalam entri milis ini dari 09/2015 (kemungkinan ini telah ditambal):
Perbedaannya adalah kami memiliki kode untuk mendeteksi perangkat yang tidak ada di mount, kami belum memiliki kode (belum) untuk mendeteksinya jatuh pada sistem file yang terpasang. Mengapa memiliki deteksi yang tepat untuk perangkat yang menghilang tampaknya bukan prioritas, saya tidak tahu, tetapi itu adalah masalah terpisah dari perilaku pemasangan.
https://www.mail-archive.com/[email protected]/msg46598.html
Akan ada banyak sekali pesan kesalahan di dmesg saat itu, jadi mengambil dmesg mungkin tidak dapat diandalkan.
Untuk server yang menggunakan BTRFS, mungkin merupakan ide untuk memiliki pemeriksaan khusus (tugas cron) yang mengirimkan peringatan jika setidaknya salah satu drive dalam larik RAID hilang, yaitu tidak dapat diakses lagi...
Sejak btrfs-progs v4.11.1 stats memiliki opsi --check yang akan mengembalikan bukan nol jika salah satu nilainya bukan nol, menghilangkan kebutuhan akan regex.
statistik perangkat -c /
Saya tidak akan mengandalkan perintah stats untuk pemberitahuan kesalahan, karena perintah ini tidak mengembalikan kesalahan jika drive tiba-tiba hilang. Anda dapat mengujinya dengan mencabut kabel sata atau menarik drive - tidak disarankan dengan sistem file penting.
btrfs device stats /
Setelah reboot, btrfs menunjukkan drive yang hilang, tapi itu mungkin sudah terlambat.
btrfs fi show