Lỗi đĩa im lặng và độ tin cậy của trao đổi Linux

Tôi hiểu rằng các ổ đĩa cứng và SSD thực hiện một số sửa lỗi cơ bản bên trong ổ đĩa và hầu hết các cấu hình RAID, ví dụ: mdadm sẽ phụ thuộc vào điều này để quyết định khi nào một ổ đĩa không sửa lỗi và cần phải ngoại tuyến. Tuy nhiên, điều này phụ thuộc vào việc lưu trữ chính xác 100% trong chẩn đoán lỗi. Điều đó không phải vậy, và một cấu hình phổ biến như gương RAID-1 hai ổ đĩa sẽ dễ bị tổn thương: giả sử một số bit trên một ổ đĩa bị hỏng âm thầm và ổ đĩa không báo lỗi đọc. Do đó, các hệ thống tệp như btrfs và ZFS thực hiện tổng kiểm riêng của họ, để không tin tưởng vào các phần cứng ổ đĩa lỗi, cáp SATA rối rắm, v.v.

Tương tự, RAM cũng có thể có vấn đề về độ tin cậy và do đó chúng ta có RAM ECC để giải quyết vấn đề này.

Câu hỏi của tôi là : cách thức kinh điển để bảo vệ tệp hoán đổi Linux khỏi sự hỏng hóc im lặng / thối bit không bị bắt bởi phần sụn ổ đĩa trên cấu hình hai đĩa (tức là sử dụng trình điều khiển hạt nhân chính)? Dường như với tôi rằng một cấu hình thiếu bảo vệ đầu cuối ở đây (chẳng hạn như được cung cấp bởi btrfs) phần nào phủ nhận sự an tâm do RAM ECC mang lại. Tuy nhiên, tôi không thể nghĩ ra một cách hay:

• btrfs hoàn toàn không hỗ trợ hoán đổi. Bạn có thể thiết lập một thiết bị lặp từ tệp btrfs và thực hiện trao đổi trên đó. Nhưng điều đó có vấn đề:
  • Viết ngẫu nhiên không hoạt động tốt: https://btrfs.wiki.kernel.org/index.php/Gotchas#Frag sắc
  • Đề xuất ở đó để vô hiệu hóa sao chép khi ghi cũng sẽ vô hiệu hóa kiểm tra - do đó đánh bại toàn bộ điểm của bài tập này. Giả định của họ là tệp dữ liệu có các biện pháp bảo vệ nội bộ riêng.
• ZFS trên Linux cho phép sử dụng ZVOL làm trao đổi, mà tôi đoán có thể hoạt động: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - tuy nhiên, từ việc đọc của tôi, ZFS thường yêu cầu bộ nhớ và làm cho nó hoạt động trong một trao đổi ứng dụng chỉ nghe có vẻ như một số công việc tìm ra nó. Tôi nghĩ rằng đây không phải là lựa chọn đầu tiên của tôi. Tại sao bạn phải sử dụng một số mô-đun hạt nhân ngoài luồng chỉ để có một trao đổi đáng tin cậy nằm ngoài tôi - chắc chắn có một cách để thực hiện điều này với hầu hết các bản phân phối / hạt nhân Linux hiện đại trong thời đại ngày nay?
• Thực sự có một luồng trong danh sách gửi thư nhân Linux với các bản vá để kích hoạt tổng kiểm tra trong chính trình quản lý bộ nhớ, vì chính xác những lý do tôi thảo luận trong câu hỏi này: http://thread.gmane.org/gmane.linux.kernel/989246 - Thật không may, theo như tôi có thể nói, bản vá đã chết và không bao giờ khiến nó ngược dòng vì những lý do mà tôi không biết. Quá tệ, nó có vẻ như là một tính năng tốt. Mặt khác, nếu bạn đặt trao đổi trên RAID-1 - nếu hỏng vượt quá khả năng sửa chữa của tổng kiểm tra, bạn sẽ muốn trình quản lý bộ nhớ thử đọc từ ổ đĩa khác trước khi hoảng loạn hoặc bất cứ điều gì, đó là có lẽ nằm ngoài phạm vi của những gì một người quản lý bộ nhớ nên làm.

Tóm tắt:

• RAM có ECC để sửa lỗi
• Các tệp trên bộ nhớ vĩnh viễn có btrfs để sửa lỗi
• Hoán đổi có ??? <--- đây là câu hỏi của tôi

Chúng tôi tin tưởng vào tính toàn vẹn của dữ liệu được lấy từ trao đổi vì phần cứng lưu trữ có tổng kiểm tra, CRC và như vậy.

Trong một trong những ý kiến ​​trên, bạn nói:

đúng, nhưng nó sẽ không bảo vệ chống lại các bit lật bên ngoài đĩa

"Nó" có nghĩa là tổng kiểm tra của đĩa ở đây.

Điều đó là đúng, nhưng SATA sử dụng CRC 32 bit cho các lệnh và dữ liệu. Do đó, bạn có 1 trong 4 tỷ cơ hội làm hỏng dữ liệu mà không thể phát hiện được giữa đĩa và bộ điều khiển SATA. Điều đó có nghĩa là một nguồn lỗi liên tục có thể gây ra lỗi thường xuyên như mọi 125 MiB được chuyển, nhưng một nguồn lỗi ngẫu nhiên, hiếm gặp như tia vũ trụ sẽ gây ra các lỗi không thể phát hiện được với tốc độ nhỏ.

Cũng nhận ra rằng nếu bạn có một nguồn gây ra lỗi không bị phát hiện ở tốc độ gần một trên mỗi 125 MiB được chuyển, hiệu suất sẽ rất tệ vì số lượng lỗi được phát hiện yêu cầu chuyển lại cao. Theo dõi và đăng nhập có thể sẽ cảnh báo bạn về vấn đề kịp thời để tránh tham nhũng không bị phát hiện.

Đối với tổng kiểm tra của phương tiện lưu trữ, mọi đĩa SATA (và trước đó, PATA) đều sử dụng một số tổng kiểm tra theo từng lĩnh vực. Một trong những tính năng đặc trưng của đĩa cứng "doanh nghiệp" là các khu vực lớn hơn được bảo vệ bởi các tính năng toàn vẹn dữ liệu bổ sung , giúp giảm đáng kể khả năng xảy ra lỗi không bị phát hiện.

Nếu không có các biện pháp như vậy, sẽ không có điểm nào cho nhóm khu vực phụ tùng trong mọi ổ đĩa cứng: bản thân ổ đĩa không thể phát hiện ra một khu vực xấu, vì vậy nó không bao giờ có thể trao đổi các lĩnh vực mới trong.

Trong một bình luận khác, bạn hỏi:

Nếu SATA rất đáng tin cậy, tại sao lại có các hệ thống tệp kiểm tra như ZFS, btrfs, ReFS?

Nói chung, chúng tôi không yêu cầu trao đổi để lưu trữ dữ liệu lâu dài. Giới hạn lưu trữ trao đổi là thời gian hoạt động của hệ thống và hầu hết dữ liệu trong trao đổi không kéo dài gần như vậy, vì hầu hết dữ liệu đi qua hệ thống bộ nhớ ảo của hệ thống của bạn thuộc về các quy trình có thời gian ngắn hơn nhiều.

Trên hết, thời gian tăng thường giảm dần qua các năm, với tần suất tăng của kernel và libccập nhật, ảo hóa, kiến ​​trúc đám mây, v.v.

Hơn nữa, hầu hết dữ liệu trao đổi vốn đã bị vô hiệu hóa trong một hệ thống được quản lý tốt, là một dữ liệu không tự chạy ra khỏi RAM chính. Trong một hệ thống như vậy, những thứ duy nhất kết thúc trong trao đổi là các trang mà chương trình không sử dụng thường xuyên, nếu có. Điều này là phổ biến hơn bạn có thể đoán. Hầu hết các thư viện động mà các chương trình của bạn liên kết để có các thường trình mà chương trình của bạn không sử dụng, nhưng chúng phải được tải vào RAM bởi trình liên kết động . Khi HĐH thấy rằng bạn không sử dụng tất cả văn bản chương trình trong thư viện, nó sẽ tráo đổi nó, nhường chỗ cho mã và dữ liệu mà chương trình của bạn đang sử dụng. Nếu các trang bộ nhớ bị tráo đổi như vậy bị hỏng, ai sẽ biết?

Tương phản điều này với ZFS, nơi chúng tôi hy vọng dữ liệu sẽ được lưu trữ lâu dài và bền vững, để nó không chỉ vượt quá thời gian hoạt động hiện tại của hệ thống, mà còn vượt ra ngoài tuổi thọ của các thiết bị lưu trữ riêng lẻ bao gồm hệ thống lưu trữ. ZFS và như vậy đang giải quyết một vấn đề với thang thời gian dài hơn hai bậc so với vấn đề được giải quyết bằng trao đổi. Do đó, chúng tôi có các yêu cầu phát hiện tham nhũng cho ZFS cao hơn nhiều so với trao đổi Linux.

ZFS và như vậy khác với trao đổi theo một cách quan trọng khác ở đây: chúng tôi không trao đổi hệ thống tập tin RAID với nhau. Khi nhiều thiết bị trao đổi được sử dụng trên một máy, đó là sơ đồ JBOD , không giống như RAID-0 hoặc cao hơn. (ví dụ như hệ điều hành MacOS của xích các file swap của chương trình , Linux swapon, vv) Kể từ khi thiết bị hoán đổi là độc lập, chứ không phải phụ thuộc lẫn nhau như với RAID, chúng ta không cần checksumming rộng vì thay thế một thiết bị trao đổi không liên quan đến nhìn vào các thiết bị phụ thuộc lẫn nhau trao đổi khác cho dữ liệu nên đi trên thiết bị thay thế. Theo thuật ngữ ZFS, chúng tôi không khôi phục các thiết bị hoán đổi từ các bản sao dự phòng trên các thiết bị lưu trữ khác.

Tất cả điều này không có nghĩa là bạn phải sử dụng một thiết bị trao đổi đáng tin cậy. Tôi đã từng sử dụng một bao vây USB HDD ngoài 20 đô la để giải cứu một nhóm ZFS ốm yếu, chỉ để phát hiện ra rằng bao vây đó không đáng tin cậy, đưa các lỗi của chính nó vào quá trình. Kiểm tra mạnh mẽ của ZFS đã cứu tôi ở đây. Bạn không thể thoát khỏi việc xử lý phương tiện lưu trữ ung dung như vậy với một tệp hoán đổi. Nếu thiết bị trao đổi sắp chết và do đó tiếp cận trường hợp xấu nhất có thể gây ra lỗi không thể phát hiện được sau mỗi 125 MiB được chuyển, bạn chỉ cần thay thế nó, càng sớm càng tốt.

Ý nghĩa tổng thể của hoang tưởng trong câu hỏi này phá hủy một ví dụ của vấn đề tướng quân Byzantine . Đọc về điều đó, suy ngẫm về ngày 1982 trên bài báo học thuật mô tả vấn đề với thế giới khoa học máy tính, và sau đó quyết định xem bạn, vào năm 2019, có những suy nghĩ mới mẻ để thêm vào vấn đề này hay không. Và nếu không, thì có lẽ bạn sẽ chỉ sử dụng công nghệ được thiết kế bởi ba thập kỷ sinh viên tốt nghiệp CS, những người đều biết về vấn đề của tướng Byzantine.

Đây là mặt đất tốt. Bạn có thể không thể đưa ra một ý tưởng, sự phản đối hoặc giải pháp chưa được thảo luận cho đến chết trên các tạp chí khoa học máy tính.

SATA chắc chắn không hoàn toàn đáng tin cậy, nhưng trừ khi bạn sẽ tham gia vào học viện hoặc một trong các nhóm phát triển hạt nhân, bạn sẽ không ở vị trí để thêm vật chất vào tình trạng của nghệ thuật ở đây. Những vấn đề này đã có sẵn, như bạn đã lưu ý: ZFS, btrfs, ReFS ... Là người dùng HĐH, bạn chỉ cần tin tưởng rằng những người tạo ra HĐH đang chăm sóc những vấn đề này cho bạn, vì họ cũng biết về các tướng Byzantine.

Đó là hiện không thực tế để đưa tập tin trao đổi của bạn trên đầu trang của ZFS hoặc btrfs, nhưng nếu ở trên không làm bạn yên tâm, ít nhất bạn có thể đặt nó trên đỉnh xfs hoặc ext4. Điều đó sẽ tốt hơn so với việc sử dụng một phân vùng trao đổi chuyên dụng.

dm-liêm chính

Xem: Tài liệu / thiết bị ánh xạ / dm-vẹn.txt

dm-integritythông thường sẽ được sử dụng trong chế độ nhật ký. Trong trường hợp trao đổi, bạn có thể sắp xếp để làm mà không cần nhật ký. Điều này có thể làm giảm đáng kể chi phí hiệu suất. Tôi không chắc liệu bạn có cần định dạng lại phân vùng trao đổi toàn vẹn trên mỗi lần khởi động hay không, để tránh bắt lỗi sau khi tắt máy ô uế.

Trong thông báo ban đầudm-integrity , tác giả nêu ưu tiên "bảo vệ tính toàn vẹn dữ liệu ở cấp độ cao hơn". Trong trường hợp trao đổi, điều đó sẽ mở ra khả năng lưu trữ tổng kiểm tra trong RAM. Tuy nhiên, tùy chọn đó sẽ yêu cầu sửa đổi không tầm thường đối với mã hoán đổi hiện tại và tăng mức sử dụng bộ nhớ. (Mã hiện tại theo dõi trao đổi hiệu quả bằng cách sử dụng phạm vi, không phải các trang / lĩnh vực riêng lẻ).

DIF / DIX?

Hỗ trợ DIX đã được Oracle thêm vào trong Linux 2.6.27 (2008).

Việc sử dụng DIX có cung cấp tính toàn vẹn từ đầu đến cuối không?

Bạn có thể tham khảo ý kiến ​​nhà cung cấp của bạn. Tôi không biết làm thế nào bạn có thể nói nếu họ nói dối về điều đó.

DIX được yêu cầu để bảo vệ dữ liệu trong chuyến bay giữa HĐH (hệ điều hành) và HBA .

DIF tự tăng khả năng bảo vệ dữ liệu trong chuyến bay giữa HBA và thiết bị lưu trữ . (Xem thêm: trình bày với một số số liệu về sự khác biệt về tỷ lệ lỗi ).

Chính xác bởi vì tổng kiểm tra trong trường bảo vệ được chuẩn hóa, về mặt kỹ thuật có thể thực hiện các lệnh DIX mà không cung cấp bất kỳ sự bảo vệ nào cho dữ liệu khi nghỉ ngơi. Chỉ cần có HBA (hoặc thiết bị lưu trữ) tạo lại tổng kiểm tra tại thời điểm đọc. Triển vọng này đã được thực hiện khá rõ ràng bởi dự án DIX ban đầu.

• DIF / DIX là tổng kiểm tra khối trực giao
  • Chúng tôi vẫn yêu bạn, btrfs!
  • Lỗi tổng kiểm tra khối logic được sử dụng để phát hiện dữ liệu bị hỏng
  • Phát hiện xảy ra tại thời điểm ĐỌC
  • ... có thể là vài tháng sau, bộ đệm ban đầu bị mất
  • Bất kỳ bản sao dự phòng nào cũng có thể xấu nếu bộ đệm ban đầu bị cắt xén
• DIF / DIX chủ động ngăn ngừa tham nhũng
  • Ngăn chặn dữ liệu xấu được lưu trữ trên đĩa ở nơi đầu tiên
  • ... và tìm hiểu về các vấn đề trước khi bộ đệm ban đầu bị xóa khỏi bộ nhớ

- lpc08-data-vẹn.pdf từ oss.oracle.com

Một trong những bài đăng đầu tiên của họ về DIX đề cập đến khả năng sử dụng DIX giữa OS và HBA ngay cả khi ổ đĩa không hỗ trợ DIF.

Hoàn thành dự thảo tương đối khó xảy ra trong bối cảnh "doanh nghiệp" nơi DIX hiện đang được sử dụng; mọi người sẽ chú ý đến nó Ngoài ra, DIF dựa trên phần cứng hiện có có thể được định dạng với các cung từ 520 byte. Giao thức sử dụng DIF bị cáo buộc yêu cầu bạn trước tiên định dạng lại ổ đĩa, xem ví dụ sg_formatlệnh.

Những gì có nhiều khả năng là một thực hiện không theo nguyên tắc đầu cuối thực sự . Để đưa ra một ví dụ, một nhà cung cấp được đề cập hỗ trợ tùy chọn tổng kiểm tra yếu hơn cho DIX để lưu chu kỳ CPU, sau đó được thay thế bằng tổng kiểm tra mạnh hơn trong ngăn xếp. Điều này rất hữu ích, nhưng nó không hoàn thành bảo vệ đầu cuối.

Ngoài ra, một hệ điều hành có thể tạo tổng kiểm riêng và lưu trữ chúng trong không gian thẻ ứng dụng. Tuy nhiên , không có hỗ trợ cho điều này trong Linux hiện tại (v4.20) . Nhận xét, được viết vào năm 2014, cho thấy điều này có thể là do "rất ít thiết bị lưu trữ thực sự cho phép sử dụng không gian thẻ ứng dụng". (Tôi không chắc chắn liệu điều này đề cập đến chính thiết bị lưu trữ, HBA hay cả hai).

Loại thiết bị DIX nào khả dụng với Linux?

Việc phân tách bộ đệm siêu dữ liệu và toàn vẹn dữ liệu cũng như lựa chọn trong tổng kiểm tra được gọi là Phần mở rộng toàn vẹn dữ liệu [DIX]. Vì các phần mở rộng này nằm ngoài phạm vi của các cơ quan giao thức (T10, T13), Oracle và các đối tác của nó đang cố gắng tiêu chuẩn hóa chúng trong Hiệp hội Công nghiệp Mạng Lưu trữ.

- v4.20 / Tài liệu / khối / data-vẹn.txt

Wikipedia cho tôi biết DIF được chuẩn hóa trong NVMe 1.2.1. Đối với các HBA SCSI, có vẻ hơi khó để xác định điều này nếu chúng ta không có tiêu chuẩn để chỉ ra. Tại thời điểm này có thể chính xác nhất để nói về hỗ trợ "Linux DIX" :-). Có sẵn các thiết bị:

SCSI T10 DIF / DIX [sic] được hỗ trợ đầy đủ trong Red Hat Enterprise Linux 7.4, với điều kiện nhà cung cấp phần cứng đã đủ điều kiện và cung cấp hỗ trợ đầy đủ cho cấu hình mảng lưu trữ và HBA cụ thể. DIF / DIX không được hỗ trợ trên các cấu hình khác, nó không được hỗ trợ để sử dụng trên thiết bị khởi động và nó không được hỗ trợ cho khách ảo.

Tại thời điểm hiện tại, các nhà cung cấp sau đây được biết là cung cấp hỗ trợ này ...

- Ghi chú phát hành RHEL 7.5, Chương 16. Lưu trữ

Tất cả phần cứng được đề cập trong ghi chú phát hành RHEL 7.5 là Kênh sợi quang.

Tôi không biết thị trường này. Có vẻ như DIX có thể trở nên phổ biến rộng rãi hơn trong các máy chủ trong tương lai. Tôi không biết bất kỳ lý do nào khiến nó trở nên khả dụng cho các đĩa SATA tiêu dùng - theo như tôi biết thậm chí không có một tiêu chuẩn thực tế nào cho định dạng lệnh. Tôi sẽ quan tâm xem liệu nó có trở nên phổ biến rộng rãi hơn trên NVMe không.

Hoán đổi có ??? <--- đây là câu hỏi của tôi

Hoán đổi vẫn không được bảo vệ trong Linux (nhưng xem CẬP NHẬT).

Chà, tất nhiên là có ZFS trên Linux có khả năng lưu trữ trao đổi nhưng vẫn bị khóa trong một số trường hợp - do đó thu hồi tùy chọn đó một cách hiệu quả.

Btrfs vẫn không thể xử lý các tập tin trao đổi . Họ đề cập đến khả năng sử dụng loopback mặc dù nó được ghi nhận là có hiệu suất kém. Có một dấu hiệu không rõ ràng rằng Linux 5 cuối cùng cũng có thể có nó (?)

Các bản vá để bảo vệ trao đổi thông thường của chính nó với tổng kiểm tra đã không làm cho nó trở thành chủ đạo.

Vì vậy, tất cả trong tất cả: không. Linux vẫn còn một khoảng cách ở đó.

CẬP NHẬT. : Như @ sourcejedi chỉ ra rằng có một công cụ như dm-vẹn. Nhân Linux kể từ phiên bản 4.12 đã nhận được mục tiêu của trình ánh xạ thiết bị có thể được sử dụng để cung cấp tổng kiểm tra cho bất kỳ thiết bị khối chung nào và những thiết bị trao đổi không phải là ngoại lệ. Công cụ này không được tích hợp rộng rãi vào các bản phát hành chính và hầu hết trong số chúng không có bất kỳ sự hỗ trợ nào trong hệ thống phụ của udev, nhưng cuối cùng điều này sẽ thay đổi. Khi được kết hợp với một nhà cung cấp dự phòng, giả sử đặt lên đỉnh MD hay còn gọi là Linux Software RAID, không chỉ có thể phát hiện sự thối bit mà còn định tuyến lại yêu cầu I / O đến dữ liệu lành mạnh vì tính toàn vẹn của dm sẽ cho thấy có một vấn đề và MD nên xử lý nó.

Tôi không nghĩ rằng có một cách "kinh điển", vì vậy sau đây là ý kiến ​​cá nhân của tôi.

Đã theo dõi sự tiến bộ của btrfs từ quan điểm của người dùng tiềm năng, tôi phải nói rằng nó vẫn còn mơ hồ với tôi. Có những tính năng đã trưởng thành và sẵn sàng để sử dụng sản xuất, và có những tính năng dường như chưa trưởng thành và nguy hiểm khi sử dụng.

Cá nhân, tôi không có thời gian để quyết định sử dụng tính năng nào và không, hãy bỏ qua thời gian mà tôi cần để tìm ra cách tắt hoặc bật các tính năng này.

Ngược lại, ZFS là rock-solid và trưởng thành (IMHO). Vì vậy, để trả lời câu hỏi của bạn, tôi sẽ sử dụng ZFS (nhân tiện, nó không tiêu tốn nhiều bộ nhớ - xem bên dưới).

Nhưng đối với bạn, btrfs có thể là lựa chọn đúng đắn vì bạn đã sử dụng nó (nếu tôi hiểu đúng về bạn) và một trong những ý kiến ​​trên cho thấy cách sử dụng nó để trao đổi.

Tình cờ, tôi đã đưa một số máy chủ Linux lên ZFS trong những ngày qua, mỗi lần bao gồm hệ thống tệp gốc và trao đổi. Trước khi tôi làm điều này, tôi đã thực hiện một số nghiên cứu rất kỹ lưỡng, điều đó khiến tôi mất vài ngày. Một bản tóm tắt ngắn gọn về những gì tôi đã học được:

Tiêu thụ bộ nhớ của ZFS

Có một sự hiểu lầm phổ biến về mức tiêu thụ bộ nhớ của ZFS. ZFS thường không tiêu thụ nhiều bộ nhớ; thực tế, nó chạy với TB lưu trữ trên các máy có RAM 2 GB. Chỉ khi bạn sử dụng tính năng chống trùng lặp (tắt theo mặc định), thì nó mới cần rất nhiều RAM.

Phát hiện / sửa lỗi phần cứng

Cho dù các cơ chế phát hiện / sửa lỗi của SATA, PATA, RAID hay các cơ chế sửa lỗi khác đều đủ để đảm bảo tính toàn vẹn dữ liệu là một chủ đề gây ra các cuộc thảo luận bất tận và thậm chí là chiến tranh bùng nổ ở mọi nơi trên mạng. Theo lý thuyết, một thiết bị lưu trữ phần cứng phải báo cáo (và có thể sửa) bất kỳ lỗi nào mà nó gặp phải và phần cứng truyền dữ liệu ở tất cả các cấp (chipset, bộ nhớ, v.v.) cũng sẽ làm như vậy.

Chà, trong mọi trường hợp, họ không phản ứng với những lỗi đáng kinh ngạc. Ví dụ, hãy lấy cấu hình RAID5 điển hình. Thông thường, nếu một đĩa có vấn đề, nó sẽ báo cáo với RAID, từ đó xây dựng dữ liệu được đọc từ các đĩa khác và truyền lại, nhưng cũng ghi lại vào đĩa bị lỗi (do đó có thể sẽ sửa lại ngành trước khi viết dữ liệu); nếu cùng một đĩa báo quá nhiều lỗi, RAID sẽ ngoại tuyến và thông báo cho quản trị viên (nếu được cấu hình đúng cách).

Cho đến nay, rất tốt, nhưng có những trường hợp dữ liệu bị lỗi ra khỏi đĩa mà không có đĩa báo lỗi (xem phần tiếp theo). Hầu hết các RAID có thể phát hiện tình huống này bằng cách sử dụng thông tin chẵn lẻ, nhưng phản ứng của họ là ngu ngốc: Thay vì báo cáo lỗi và ngăn dữ liệu được truyền lại, họ sẽ chỉ tính lại tính chẵn lẻ dựa trên dữ liệu bị lỗi và viết chẵn lẻ mới cho tương đương đĩa, do đó đánh dấu dữ liệu bị lỗi là chính xác mãi mãi.

Đó có phải là một hành vi hợp lý? Theo như tôi biết, hầu hết các bộ điều khiển RAID5 phần cứng và thậm chí cả md RAID của Linux đều vận hành theo cách này.

Tôi không biết về sửa lỗi của btrfs, nhưng cuối cùng bạn nên đọc kỹ tài liệu một lần nữa, đáng chú ý nếu bạn đang sử dụng RAID của btrfs.

Thối bit im lặng

Bất chấp tất cả các cuộc chiến nảy lửa và các cuộc thảo luận khoa học (giả), thực tế khác với lý thuyết, và sự thối bit im lặng chắc chắn xảy ra mặc dù lý thuyết có thể nói ngược lại (thối bot im lặng thường có nghĩa là dữ liệu trên bộ lưu trữ phần cứng bị hỏng mà không có thiết bị lưu trữ báo cáo lỗi khi dữ liệu này được đọc, nhưng tôi sẽ thêm các bit lật ở bất cứ đâu trong đường truyền đến định nghĩa này).

Rằng điều này xảy ra không phải là ý kiến ​​cá nhân của tôi: Ít nhất Google, Amazon và CERN đã xuất bản các trang trắng chi tiết bao gồm chính xác chủ đề đó. Các giấy tờ được công khai để tải về miễn phí. Họ đã thực hiện các thí nghiệm có hệ thống với hàng triệu đĩa cứng và hàng trăm nghìn máy chủ / thiết bị lưu trữ, vì họ gặp vấn đề với tham nhũng dữ liệu không được phát hiện hoặc vì họ muốn biết phải làm gì để ngăn chặn điều đó trước khi nó xảy ra.

Tóm lại, dữ liệu trong các trang trại máy chủ của họ đã bị hỏng với tốc độ cao hơn đáng kể so với thống kê của MTBF hoặc lý thuyết khác sẽ cho phép. Cao hơn đáng kể, tôi có nghĩa là các đơn đặt hàng cường độ.

Vì vậy, mục đích bit im lặng, tức là không phát hiện được dữ liệu tại bất kỳ điểm nào trong đường truyền, là một vấn đề thực tế trong cuộc sống.

Tuổi thọ dữ liệu

Warren Young đã đúng khi nói rằng dữ liệu hoán đổi có thời gian tồn tại ngắn. Nhưng tôi muốn thêm vào sự cân nhắc sau: Không chỉ dữ liệu (theo nghĩa là tài liệu) được trao đổi, mà (thậm chí nhiều khả năng) các phần của O / S hoặc phần mềm đang chạy khác . Nếu tôi có một MP3 trong trao đổi, tôi có thể sống với một bit lật. Nếu (do một tình huống cực đoan) các phần của phần mềm máy chủ httpd sản xuất của tôi bị hoán đổi, tôi không bao giờ có thể sống với một bit lật mà sau đó dẫn đến thực thi mã bị hỏng nếu không bị phát hiện.

Phần kết

Đối với tôi, ZFS giải quyết các vấn đề này, hay chính xác hơn là nó di chuyển chúng ra khỏi các đĩa vào bộ nhớ và do đó làm giảm khả năng bị thối bit im lặng theo một số bậc độ lớn. Hơn nữa, nếu được cấu hình đúng (ví dụ như gương thay vì RAID), nó sẽ cung cấp một sửa lỗi sạch và hợp lý, hoạt động như mong đợi và có thể hiểu được một cách dễ dàng.

Đã nói điều này, xin lưu ý rằng bạn sẽ không bao giờ có được sự an toàn tuyệt đối. Cá nhân, tôi tin tưởng RAM ECC của tôi nhiều hơn các ổ đĩa của tôi và tôi tin rằng ZFS với tổng kiểm tra từ đầu đến cuối của nó làm giảm xác suất vấn đề theo các đơn đặt hàng cường độ. Tuy nhiên, tôi không bao giờ khuyên bạn nên sử dụng ZFS mà không có RAM ECC.

Tuyên bố miễn trừ trách nhiệm: Tôi không liên quan đến bất kỳ nhà cung cấp hoặc nhà phát triển ZFS nào. Điều này đúng với tất cả các biến thể (dĩa) của ZFS. Tôi chỉ trở thành một fan hâm mộ của nó trong những ngày qua ...