phát hiện và sửa lỗi quay bit với mdadm

Tôi sắp tổ chức lại tất cả các ổ cứng của mình trong hộp linux tại nhà và muốn sử dụng cuộc đột kích mdadm để bảo vệ dữ liệu và tính linh hoạt của nó để định hình lại các mảng. Tuy nhiên, trước khi tôi sử dụng mdadm cho điều này, tôi muốn biết làm thế nào nó xử lý mục nát bit . Cụ thể là các loại mục nát bit không dẫn đến các thông báo lỗi đọc không thể phục hồi được gửi từ ổ cứng.

Vì tôi có thể sẽ sử dụng ít nhất 21TB ổ cứng trong 8 ổ đĩa và nhiều trích dẫn khác nhau về xác suất xảy ra lỗi trên ổ cứng, tôi nghĩ rằng trong quá trình xây dựng lại từ một lỗi đĩa đơn, tôi rất có thể gặp phải một số dạng thối bit trên các đĩa còn lại. Nếu đó là lỗi đọc không thể phục hồi trên 1 trong số các ổ đĩa, thì ổ đĩa đó thực sự báo cáo đó là lỗi, tôi tin rằng nó sẽ ổn với raid6 (phải không?). Tuy nhiên, nếu dữ liệu đọc từ đĩa bị hỏng nhưng không được báo cáo như vậy bởi đĩa, thì tôi không thể thấy cách này có thể được tự động sửa ngay cả với raid6. Đây có phải là một cái gì đó chúng ta cần phải quan tâm? Đưa ra bài viết Đó là năm 2010 và RAID5 vẫn hoạt độngvà những trải nghiệm thành công của tôi ở nhà và nơi làm việc, mọi thứ không nhất thiết phải cam chịu và u ám như những lời quảng cáo và tiếp thị sẽ khiến chúng tôi tin tưởng, nhưng tôi ghét phải khôi phục từ bản sao lưu chỉ vì một ổ cứng bị lỗi.

Cho rằng các kiểu sử dụng sẽ là, viết nhiều nhất một vài lần và thỉnh thoảng đọc, tôi sẽ cần thực hiện việc xóa dữ liệu . Tôi thấy trên wiki archlinux các lệnh mdadm để xóa dữ liệu một mảng như

echo check > /sys/block/md0/md/sync_action

sau đó để theo dõi tiến độ

cat /proc/mdstat

Điều này đối với tôi có vẻ như nó sẽ đọc tất cả các lĩnh vực của tất cả các đĩa và kiểm tra xem dữ liệu có khớp với chẵn lẻ và ngược lại không. Mặc dù tôi nhận thấy có sự nhấn mạnh trong các tài liệu để nói rằng có những trường hợp quan trọng rằng thao tác "kiểm tra" sẽ không thể tự động sửa, chỉ phát hiện và nó sẽ để người dùng sửa.

Tôi nên chọn cấp độ mdadm RAID nào để tối đa hóa khả năng bảo vệ khỏi bị thối bit và tôi nên thực hiện các bước bảo vệ và các bước bảo vệ nào khác? Và điều này sẽ không bảo vệ tôi khỏi?

Chỉnh sửa: Tôi không muốn bắt đầu RAID so với ZFS hoặc bất kỳ QA công nghệ nào khác. Tôi muốn biết cụ thể về cuộc đột kích mdadm. Đó cũng là lý do tại sao tôi hỏi về Unix & Linux chứ không phải trên SuperUser .

Chỉnh sửa: là câu trả lời: mdadm chỉ có thể sửa các URE được hệ thống đĩa báo cáo trong quá trình xóa dữ liệu và phát hiện sự thối bit im lặng trong quá trình chà nhưng không thể / sẽ không khắc phục được?

Thành thật mà nói, tôi thấy khá ngạc nhiên khi bạn từ chối RAIDZ2 ZFS. Nó dường như phù hợp với nhu cầu của bạn gần như hoàn hảo, ngoại trừ thực tế đó không phải là Linux MD. Tôi không tham gia vào cuộc thập tự chinh để đưa ZFS đến với công chúng, nhưng thực tế đơn giản là bạn là một trong những vấn đề mà ZFS được thiết kế từ đầu để giải quyết. Dựa vào RAID (bất kỳ RAID "thông thường" nào) để cung cấp khả năng phát hiện và sửa lỗi có thể trong tình huống giảm hoặc không dư thừa có vẻ rủi ro. Ngay cả trong trường hợp ZFS không thể sửa lỗi dữ liệu đúng cách, ít nhất nó cũng có thể phát hiện ra lỗi và cho bạn biết rằng có vấn đề, cho phép bạn thực hiện hành động khắc phục.

Bạn không cần phải thực hiện tẩy tế bào chết đầy đủ thường xuyên với ZFS, mặc dù đó là cách thực hành được khuyến nghị. ZFS sẽ xác minh rằng dữ liệu đọc từ đĩa khớp với dữ liệu được ghi khi dữ liệu đang được đọc và trong trường hợp không khớp (a) sử dụng dự phòng để tái tạo dữ liệu gốc hoặc (b) báo cáo lỗi I / O ứng dụng. Ngoài ra, chà là một hoạt động trực tuyến, ưu tiên thấp, khác với kiểm tra hệ thống tệp trong hầu hết các hệ thống tệp có thể có mức độ ưu tiên cao và ngoại tuyến. Nếu bạn đang chạy chà và một cái gì đó không phải là chà muốn làm I / O, thì chà sẽ ngồi ở ghế sau trong suốt thời gian. Một bộ lọc ZFS thay thế cho cả bộ lọc RAID và dữ liệu và siêu dữ liệu của hệ thống tệp Kiểm tra tính toàn vẹn, vì vậy kỹ lưỡng hơn rất nhiều so với việc chỉ quét mảng RAID để phát hiện bất kỳ sự thối bit nào (điều này không cho bạn biết liệu dữ liệu có ý nghĩa gì hay không, chỉ có điều nó được ghi bởi bộ điều khiển RAID).

Dự phòng ZFS (RAIDZ, phản chiếu, ...) có lợi thế là các vị trí đĩa không sử dụng không cần phải kiểm tra tính nhất quán trong quá trình chà; chỉ có dữ liệu thực tế được kiểm tra trong quá trình chà, vì các công cụ đi theo chuỗi khối phân bổ. Điều này giống như với một hồ bơi không dư thừa. Đối với RAID "thông thường", tất cả dữ liệu (bao gồm mọi vị trí không sử dụng trên đĩa) phải được kiểm tra vì bộ điều khiển RAID (dù là phần cứng hay phần mềm) không biết dữ liệu nào thực sự có liên quan.

Bằng cách sử dụng RAIDZ2 vdevs, bất kỳ hai ổ đĩa cấu thành nào cũng có thể bị lỗi trước khi bạn có nguy cơ mất dữ liệu thực tế do lỗi ổ đĩa khác, vì bạn có giá trị dự phòng của hai ổ đĩa. Điều này về cơ bản giống như RAID6.

Trong ZFS, tất cả dữ liệu, cả dữ liệu người dùng và siêu dữ liệu, đều được kiểm tra (trừ khi bạn chọn không, nhưng điều đó được khuyến nghị) và các tổng kiểm tra này được sử dụng để xác nhận rằng dữ liệu không thay đổi vì bất kỳ lý do nào. Một lần nữa, nếu tổng kiểm tra không khớp với giá trị mong đợi, dữ liệu sẽ được xây dựng lại trong suốt hoặc lỗi I / O sẽ được báo cáo. Nếu một lỗi I / O được báo cáo hoặc chà xác định một tệp bị hỏng, bạn sẽ biết thực tế là dữ liệu trong tệp đó có khả năng bị hỏng và có thể khôi phục tệp cụ thể đó từ bản sao lưu; không cần khôi phục mảng đầy đủ.

Đồng bằng, thậm chí là tương đương kép, RAID không bảo vệ bạn trước các tình huống như khi một ổ đĩa bị lỗi và một lần nữa đọc dữ liệu không chính xác khỏi đĩa. Giả sử một ổ đĩa bị lỗi và có một lần lật bất kỳ nơi nào từ bất kỳ ổ đĩa nào khác: đột nhiên, bạn đã không bị phát hiện tham nhũng và trừ khi bạn hài lòng với điều đó, bạn sẽ cần một cách để phát hiện ra nó. Cách để giảm thiểu rủi ro đó là kiểm tra từng khối trên đĩa và đảm bảo tổng kiểm tra không thể bị hỏng cùng với dữ liệu (bảo vệ chống lại các lỗi như ghi cao tốc, ghi mồ côi, ghi vào các vị trí không chính xác trên đĩa, v.v.), là chính xác những gì ZFS làm miễn là bật tính năng kiểm tra.

Nhược điểm duy nhất là bạn không thể dễ dàng phát triển RAIDZ vdev bằng cách thêm thiết bị vào nó. Có cách giải quyết cho vấn đề đó, thường liên quan đến những thứ như các tệp thưa thớt như các thiết bị trong vdev và thường được gọi là "Tôi sẽ không làm điều này nếu đó là dữ liệu của tôi". Do đó, nếu bạn đi theo tuyến RAIDZ (bất kể bạn đi với RAIDZ, RAIDZ2 hay RAIDZ3), bạn cần quyết định trước số lượng ổ đĩa bạn muốn trong mỗi vdev. Mặc dù số lượng ổ đĩa trong vdev là cố định, bạn có thể tăng dần vdev (đảm bảo duy trì trong ngưỡng dự phòng của vdev) thay thế ổ đĩa bằng ổ đĩa có dung lượng lớn hơn và cho phép bộ phục hồi hoàn toàn.

Câu trả lời này là sản phẩm của lý luận dựa trên các bằng chứng khác nhau mà tôi đã tìm thấy. Tôi không biết cách triển khai Linux kernel, vì tôi không phải là nhà phát triển kernel và dường như có rất nhiều thông tin sai lệch vô nghĩa ngoài kia. Tôi đoán rằng nhân Linux đưa ra các lựa chọn lành mạnh. Câu trả lời của tôi nên áp dụng trừ khi tôi nhầm.

Nhiều ổ đĩa sử dụng ECC (mã sửa lỗi) để phát hiện lỗi đọc. Nếu dữ liệu bị hỏng, hạt nhân sẽ nhận được URE (lỗi đọc không thể phục hồi) cho khối đó từ ổ đĩa hỗ trợ ECC. Trong những trường hợp này (và có một ngoại lệ bên dưới), sao chép dữ liệu bị hỏng hoặc trống, dữ liệu trên dữ liệu tốt sẽ gây ra sự điên rồ. Trong tình huống này, kernel nên biết dữ liệu nào tốt và dữ liệu nào xấu. Theo đó là năm 2010 và RAID5 vẫn hoạt động bài viết:

Hãy xem xét sự thay thế này, mà tôi biết sẽ được sử dụng bởi ít nhất một vài nhà cung cấp mảng. Khi một ổ đĩa trong ổ đĩa RAID báo cáo URE, bộ điều khiển mảng sẽ tăng số đếm và thỏa mãn I / O bằng cách xây dựng lại khối từ tính chẵn lẻ. Sau đó, nó thực hiện ghi lại trên đĩa đã báo cáo URE (có khả năng xác minh) và nếu khu vực xấu, microcode sẽ ánh xạ lại và tất cả sẽ ổn.

Tuy nhiên, bây giờ là ngoại lệ: nếu một ổ đĩa không hỗ trợ ECC, một ổ đĩa nói về hỏng dữ liệu hoặc phần sụn đặc biệt không hoạt động, thì URE có thể không được báo cáo và dữ liệu bị hỏng sẽ được cung cấp cho kernel. Trong trường hợp dữ liệu không khớp: có vẻ như nếu bạn đang sử dụng RAID1 2 đĩa hoặc RAID5, thì hạt nhân không thể biết dữ liệu nào là chính xác, ngay cả khi ở trạng thái không bị suy giảm, vì chỉ có một chẵn lẻ chặn và không có báo cáo URE. Trong 3 đĩa RAID1 hoặc RAID6, một khối không gắn cờ URE bị hỏng sẽ không khớp với chẵn lẻ dự phòng (kết hợp với các khối liên kết khác), do đó có thể phục hồi tự động đúng cách.

Đạo đức của câu chuyện là: sử dụng ổ đĩa với ECC. Thật không may, không phải tất cả các ổ đĩa hỗ trợ ECC đều quảng cáo tính năng này. Mặt khác, hãy cẩn thận: Tôi biết ai đó đã sử dụng ổ SSD giá rẻ trong RAID1 2 đĩa (hoặc RAID10 2 bản sao). Một trong các ổ đĩa trả về dữ liệu bị hỏng ngẫu nhiên trên mỗi lần đọc của một khu vực cụ thể. Dữ liệu bị hỏng được tự động sao chép trên dữ liệu chính xác. Nếu SSD sử dụng ECC và hoạt động đúng, thì kernel nên có hành động khắc phục thích hợp.

Để bảo vệ bạn muốn, tôi sẽ sử dụng RAID6 + sao lưu ngoại vi thông thường ở 2 vị trí.

Cá nhân tôi vẫn chà mỗi tuần một lần và sao lưu hàng đêm, hàng tuần và hàng tháng tùy thuộc vào tầm quan trọng của dữ liệu và tốc độ thay đổi.

Tôi không có đủ đại diện để bình luận, nhưng tôi muốn chỉ ra rằng hệ thống mdadm trong Linux KHÔNG sửa bất kỳ lỗi nào. Nếu bạn bảo nó "sửa" các lỗi trong quá trình xóa, RAID6, nếu có sự không nhất quán, nó sẽ "sửa" nó bằng cách giả sử các phần dữ liệu là chính xác và tính toán lại tính chẵn lẻ.

bit thối fud.? chắc chắn rồi...

Tôi đoán bạn cần nói chuyện với SEAGATE. (quên đi? đó có phải là cái cớ) không? tất cả các ổ đĩa đều có hiệu chỉnh ECC 100 bit mà bạn cần để chứng minh sự thối rữa trước tiên.
Tôi cá là bạn không thể. (đó là điều FUD đáng lo ngại phải không?) như sợ ma hay số 13? và không được thực hiện ở đây. không có bằng chứng xảy ra. và tệ hơn là không có bằng chứng về nguyên nhân.

Đầu tiên xác định bit rot có nghĩa là gì? ouch ... HDD: ECC kiểm tra dữ liệu (thậm chí 1 bit) so với bộ lưu trữ 100 bit ECC. nếu nó sai, nó sẽ sửa nó, nếu nó liên tục làm hỏng động cơ SMART, chắc chắn trên các ổ đĩa SAS, nó sẽ thay thế một cách hợp lý cụm hoặc khu vực bằng một cái tốt. sử dụng cụm phụ tùng. Điều này sửa chữa thiệt hại. Có tất cả các ổ đĩa phát triển các bit xấu từ ngày đầu đến cuối, từ các ổ đĩa đầu tiên của IBM đến NGAY BÂY GIỜ. nhưng bây giờ chúng tôi tự sửa chữa, Đọc toàn bộ giấy trắng của Seagate. vô tận ở đó, và tìm hiểu làm thế nào một ổ đĩa hoạt động. đồng ý?

điều này sẽ tiếp tục cho đến khi bạn hết phụ tùng, (não hdd, thông minh) và sau đó SMART hét lên CUỘC SỐNG. (hoặc thậm chí sớm hơn, giống như HP hiện) trên bộ điều khiển HP P420, nó luôn luôn theo dõi điều này. Tôi thậm chí còn gửi email cho tôi, hiển thị NEAR OUT OF SPARE cluster. Thỉnh thoảng các phụ tùng đi nhanh hơn, một dấu hiệu chắc chắn sẽ sớm chết, (10 tuổi sas chắc chắn, ít hơn trong sata Junky.

Tôi gọi BOGUS và FUD trên bit rot.

Tôi đoán là ai đó đồ chơi PC đã viết dữ liệu sai, vì lý do bao giờ. không chạy bộ nhớ ECC ?? Rất tiếc, máy chủ thực sự có RAM ECC. nhiễm virus.? hoặc mất điện trong quá trình ghi (không có UPS>?)? hoặc có trí nhớ kém.? hoặc bị hư hỏng. Hoặc PSU tạo ra hàng tấn tiếng ồn (xấu)

Tôi gọi FUD ở đây. lấy làm tiếc,