Normal günlük sistemine ek olarak, BTRFS'nin sürücü başına hataları (okuma, yazma ve bozulma / sağlama toplamı hataları dahil) izleyen bir istatistik komutu vardır:
# 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
Böylece basit bir kök cronjob oluşturabilirsiniz:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Bu, her saat pozitif hata sayısını kontrol eder ve size bir e-posta gönderir. Açıkçası, e-posta bildiriminin çalıştığını doğrulamak için böyle bir senaryoyu test edersiniz (örneğin bozulmaya neden olarak veya grep'i kaldırarak).
Buna ek olarak, BTRFS (sağlama toplamı olan) gibi gelişmiş dosya sistemlerinde, kötü bir sürücünün neden olduğu sessiz yolsuzluğu tespit etmek için genellikle her iki haftada bir bir fırçalama zamanlamanız önerilir.
@monthly /sbin/btrfs scrub start -Bq /data
Bu -Bseçenek fırçalamayı ön planda tutar, böylece e-posta kronundaki sonuçları size görürsünüz. Aksi takdirde, arka planda çalışır ve e-postada olmayacakları için sonuçları manuel olarak kontrol etmeyi hatırlamanız gerekir.
Güncelleme : Michael Kjörling'in önerdiği gibi grep geliştirildi, teşekkürler.
Güncelleme 2 : Ovma ve normal okuma işlemleriyle ilgili ek notlar (bu yalnızca BTRFS için geçerli değildir):
Ioan'ın işaret ettiği gibi, bir ovma, dizinin boyutuna ve türüne (ve diğer faktörlere) bağlı olarak, bazı durumlarda bir günden fazla zaman alabilir. Ve aktif bir taramadır, gelecekteki hataları algılamaz - bir fırçalamanın amacı, o zamandaki sürücülerinizdeki hataları bulmak ve düzeltmektir. Ancak diğer RAID sistemlerinde olduğu gibi, periyodik ovmaların programlanması önerilir. Dosya okumak gibi tipik bir G / Ç işleminin, okunan verilerin gerçekten doğru olup olmadığını kontrol ettiği doğrudur. Ancak basit bir ayna düşünün - dosyanın ilk kopyası hasar görürse, belki ölmek üzere olan bir sürücü tarafından, ancak doğru olan ikinci kopya aslında BTRFS tarafından okunursa, BTRFS yolsuzluk olduğunu bilmez sürücülerden birinde. Bunun nedeni, istenen verilerin alınmasıdır,Bu, özel olarak bir sürücüde bozuk olduğunu bildiğiniz bir dosyayı okuduğunuzda bile, bozulmanın bu okuma işlemi tarafından algılanacağının garantisi olmadığı anlamına gelir.
Şimdi, BTRFS'nin sadece iyi sürücüden okuduğunu varsayalım, kötü sürücüdeki hasarı tespit edecek hiçbir fırçalama yapılmıyor ve sonra iyi sürücü de kötü gidiyor - sonuç veri kaybı olacak (en azından BTRFS biliyordu) hangi dosyalar hala doğrudur ve bunları okumanıza izin verir). Tabii ki, bu basitleştirilmiş bir örnektir; gerçekte, BTRFS her zaman bir sürücüden okuma ve diğer sürücüyü göz ardı etmeyecektir.
Ancak önemli olan nokta, periyodik fırçalamaların önemli olmasıdır, çünkü düzenli okuma işlemlerinin mutlaka algılamayacağı hataları bulurlar (ve düzeltirler).
Hatalı sürücüler : Bu soru oldukça popüler olduğu için, bu "izleme çözümünün" muhtemelen kötü sürücülerle ilgili sorunları tespit etmek olduğunu belirtmek isterim (örneğin, sürücüye neden olan ölmekle birlikte hala erişilebilir).
Öte yandan, bir sürücü aniden kaybolursa (ölmek ve hata üretmek yerine bağlantısı kesilmiş veya tamamen ölmüşse), hatalı bir sürücü olacaktır (ZFS böyle bir sürücüyü FAULTED olarak işaretler). Ne yazık ki, BTRFS, 09/2015 tarihli bu posta listesi girişinde belirtildiği gibi, dosya sistemi takılıyken bir sürücünün gittiğini fark etmeyebilir (bunun yamalanmış olması mümkündür):
Aradaki fark, bir aygıtın bağlantı noktasında bulunmadığını algılamak için kodumuz olması, bağlı bir dosya sistemine düştüğünü algılamak için kodumuz (henüz) yok. Neden bir aygıtın kaybolması için uygun bir algılamanın olması bir öncelik olarak görünmüyor, hiçbir fikrim yok, ancak bu bağlanma davranışından ayrı bir konudur.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
O zamana kadar dmesg'de tonlarca hata mesajı olurdu, bu yüzden dmesg'i selamlamak güvenilir olmayabilir.
BTRFS kullanan bir sunucu için, RAID dizisindeki sürücülerden en az biri gitti, yani artık erişilemiyorsa bir uyarı gönderen özel bir kontrol (cron işi) olması bir fikir olabilir ...