Ngoài hệ thống ghi nhật ký thông thường, BTRFS còn có lệnh thống kê , theo dõi các lỗi (bao gồm lỗi đọc, ghi và lỗi tham nhũng / tổng kiểm tra) trên mỗi ổ đĩa:
# 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
Vì vậy, bạn có thể tạo một cronjob gốc đơn giản:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Điều này sẽ kiểm tra số lỗi tích cực mỗi giờ và gửi email cho bạn. Rõ ràng, bạn sẽ kiểm tra một kịch bản như vậy (ví dụ bằng cách gây ra tham nhũng hoặc xóa grep) để xác minh rằng thông báo email hoạt động.
Ngoài ra, với các hệ thống tệp nâng cao như BTRFS (đã kiểm tra lại), chúng tôi thường khuyên bạn nên lên lịch kiểm tra mỗi vài tuần để phát hiện tham nhũng thầm lặng do ổ đĩa xấu gây ra.
@monthly /sbin/btrfs scrub start -Bq /data
Các -Btùy chọn sẽ giữ chà ở mặt trước, do đó bạn sẽ thấy những kết quả trong cron email gửi cho bạn. Nếu không, nó sẽ chạy trong nền và bạn sẽ phải nhớ kiểm tra kết quả theo cách thủ công vì chúng sẽ không có trong email.
Cập nhật : Cải thiện grep theo đề xuất của Michael Kjorling, cảm ơn.
Cập nhật 2 : Ghi chú bổ sung về việc cọ rửa so với thao tác đọc thông thường (điều này không chỉ áp dụng cho BTRFS):
Như Ioan đã chỉ ra, một quá trình chà có thể mất nhiều giờ, tùy thuộc vào kích thước và loại mảng (và các yếu tố khác), thậm chí hơn một ngày trong một số trường hợp. Và nó là một hoạt động quét, nó sẽ không phát hiện ra các lỗi trong tương lai - mục tiêu của việc xóa là tìm và sửa lỗi trên các ổ đĩa của bạn tại thời điểm đó. Nhưng cũng như các hệ thống RAID khác, nên lập lịch trình định kỳ. Đúng là một thao tác i / o điển hình, như đọc một tệp, sẽ kiểm tra xem dữ liệu đã đọc có thực sự chính xác hay không. Nhưng hãy xem xét một tấm gương đơn giản - nếu bản sao đầu tiên của tệp bị hỏng, có thể do một ổ đĩa sắp chết, nhưng bản sao thứ hai, chính xác, thực sự được đọc bởi BTRFS, thì BTRFS sẽ không biết rằng có tham nhũng trên một trong các ổ đĩa. Điều này chỉ đơn giản là vì dữ liệu được yêu cầu đã được nhận,Điều này có nghĩa là ngay cả khi bạn đọc cụ thể một tệp mà bạn biết bị hỏng trên một ổ đĩa, không có gì đảm bảo rằng tham nhũng sẽ được phát hiện bởi thao tác đọc này.
Bây giờ, hãy giả sử rằng BTRFS chỉ đọc từ ổ đĩa tốt, không có hoạt động chà nào phát hiện ra thiệt hại trên ổ đĩa xấu và sau đó ổ đĩa tốt cũng bị hỏng - kết quả sẽ là mất dữ liệu (ít nhất BTRFS sẽ biết tập tin nào vẫn đúng và vẫn cho phép bạn đọc những tập tin đó). Tất nhiên, đây là một ví dụ đơn giản; trong thực tế, BTRFS sẽ không luôn luôn đọc từ một ổ đĩa và bỏ qua ổ đĩa khác.
Nhưng vấn đề là việc kiểm tra định kỳ rất quan trọng vì họ sẽ tìm thấy (và sửa) các lỗi mà các hoạt động đọc thông thường không nhất thiết phải phát hiện.
Ổ đĩa bị lỗi : Vì câu hỏi này khá phổ biến, tôi muốn chỉ ra rằng "giải pháp giám sát" này là để phát hiện các vấn đề với các ổ đĩa xấu có thể xảy ra (ví dụ: ổ đĩa chết gây ra lỗi nhưng vẫn có thể truy cập được).
Mặt khác, nếu một ổ đĩa bị mất đột ngột (bị ngắt kết nối hoặc chết hoàn toàn thay vì chết và tạo ra lỗi), đó sẽ là một ổ đĩa bị lỗi (ZFS sẽ đánh dấu một ổ đĩa đó là FAULTED). Thật không may, BTRFS có thể không nhận ra rằng một ổ đĩa đã biến mất trong khi hệ thống tập tin được gắn kết, như được chỉ ra trong mục nhập danh sách gửi thư này từ 09/2015 (có thể điều này đã được vá):
Sự khác biệt là chúng tôi có mã để phát hiện một thiết bị không có mặt tại mount, chúng tôi không có mã (chưa) để phát hiện thiết bị rơi trên hệ thống tập tin được gắn. Tại sao có phát hiện đúng cho một thiết bị biến mất dường như không phải là ưu tiên, tôi không biết, nhưng đó là một vấn đề riêng biệt với hành vi gắn kết.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
Vào thời điểm đó, có rất nhiều thông báo lỗi trong dmesg, do đó, việc đưa dmesg có thể không đáng tin cậy.
Đối với máy chủ sử dụng BTRFS, có thể nên kiểm tra tùy chỉnh (công việc định kỳ) để gửi cảnh báo nếu ít nhất một trong các ổ đĩa trong mảng RAID bị mất, tức là không thể truy cập được nữa ...