Các cải tiến của Btrfs đã được đề xuất đưa vào nhân Linux 6.2 để khắc phục sự cố lỗ ghi khi triển khai RAID 5/6. Bản chất của vấn đề là nếu xảy ra sự cố trong quá trình ghi, ban đầu không thể hiểu được khối nào trên thiết bị RAID nào được ghi chính xác và khối nào quá trình ghi chưa được hoàn thành. Nếu bạn cố gắng khôi phục RAID trong trường hợp này, các khối tương ứng với các khối được bảo lãnh có thể bị hủy do trạng thái của các khối RAID không đồng bộ. Sự cố này xảy ra ở bất kỳ mảng RAID1/5/6 nào mà các biện pháp đặc biệt chưa được thực hiện để chống lại hiệu ứng này.
Trong triển khai RAID, như RAID1 trong btrfs, vấn đề này được giải quyết bằng cách sử dụng tổng kiểm tra ở cả hai bản sao; nếu có sự không khớp, dữ liệu sẽ được khôi phục đơn giản từ bản sao thứ hai. Cách tiếp cận này cũng hoạt động nếu một số thiết bị bắt đầu gửi dữ liệu không chính xác thay vì lỗi hoàn toàn.
Tuy nhiên, trong trường hợp RAID5/6, hệ thống tệp không lưu trữ tổng kiểm tra cho các khối chẵn lẻ: trong tình huống bình thường, tính hợp lệ của các khối được xác minh bởi thực tế là tất cả chúng đều được kiểm tra tổng và khối chẵn lẻ có thể được xây dựng lại từ dữ liệu. Tuy nhiên, trong trường hợp ghi một phần, phương pháp này có thể không hiệu quả trong một số trường hợp. Trong trường hợp này, khi khôi phục một mảng, có thể các khối nằm trong bản ghi chưa hoàn chỉnh sẽ được khôi phục không chính xác.
Trong trường hợp btrfs, vấn đề này có liên quan nhất nếu bản ghi được tạo ra nhỏ hơn sọc. Trong trường hợp này, hệ thống tệp phải thực hiện thao tác đọc-sửa-ghi (đọc-sửa-ghi, RMW). Nếu điều này gặp phải các khối có nội dung ghi không đầy đủ thì thao tác RMW có thể gây ra lỗi không được phát hiện, bất kể tổng kiểm tra. Các nhà phát triển đã thực hiện các thay đổi trong đó hoạt động RMW kiểm tra tổng kiểm tra các khối trước khi thực hiện thao tác này và nếu cần khôi phục dữ liệu, nó cũng kiểm tra tổng kiểm tra sau khi ghi. Thật không may, trong trường hợp viết một sọc không hoàn chỉnh (RMW), điều này dẫn đến tốn thêm chi phí để tính tổng kiểm tra, nhưng làm tăng đáng kể độ tin cậy. Đối với RAID6, logic như vậy vẫn chưa sẵn sàng, tuy nhiên, đối với lỗi như vậy trong RAID6, việc ghi không thành công trên 2 thiết bị cùng một lúc, điều này ít xảy ra hơn.
Ngoài ra, chúng tôi có thể lưu ý các đề xuất về việc sử dụng RAID5/6 từ các nhà phát triển, bản chất của nó là trong Btrfs, siêu dữ liệu và cấu hình lưu trữ dữ liệu có thể khác nhau. Trong trường hợp này, bạn có thể sử dụng cấu hình RAID1 (bản sao) hoặc thậm chí RAID1C3 (3 bản sao) cho siêu dữ liệu và RAID5 hoặc RAID6 cho dữ liệu. Điều này một mặt đảm bảo khả năng bảo vệ siêu dữ liệu đáng tin cậy và không có “lỗ ghi”, mặt khác cũng như việc sử dụng không gian hiệu quả hơn, đặc trưng của RAID5/6. Điều này cho phép tránh tham nhũng siêu dữ liệu và có thể sửa lỗi tham nhũng dữ liệu.
Cũng có thể lưu ý rằng đối với SSD trong Btrfs trong kernel 6.2, việc thực thi không đồng bộ của thao tác “loại bỏ” sẽ được kích hoạt theo mặc định (đánh dấu các khối giải phóng không còn cần được lưu trữ vật lý). Ưu điểm của chế độ này là hiệu suất cao nhờ việc nhóm hiệu quả các hoạt động “loại bỏ” trong hàng đợi và xử lý thêm hàng đợi bằng bộ xử lý nền, đó là lý do tại sao các hoạt động FS bình thường không bị chậm lại, như trường hợp với đồng bộ “ loại bỏ” khi các khối được giải phóng và SSD có thể đưa ra quyết định tốt hơn. Mặt khác, bạn sẽ không cần sử dụng các tiện ích như fstrim nữa, vì tất cả các khối có sẵn sẽ bị xóa trong FS mà không cần quét bổ sung và không làm chậm hoạt động.
Nguồn: opennet.ru