Tại sao ZFS không làm bất cứ điều gì với khu vực duff của đĩa của tôi?

Tôi có ấn tượng rằng nếu xảy ra lỗi I / O trong quá trình đọc từ nhóm ZFS, hai điều sẽ xảy ra:

1. Thất bại sẽ được ghi lại trong thống kê READ hoặc CKSUM của thiết bị có liên quan, truyền lên phía trên tới mức pool.
2. • Dữ liệu dư thừa sẽ được sử dụng để xây dựng lại khối được yêu cầu, trả lại khối được yêu cầu cho người gọi và nếu ổ đĩa vẫn còn chức năng thì hãy viết lại khối cho nó, HOẶC
   • Một lỗi I / O sẽ được trả về nếu không có dữ liệu dư thừa để sửa lỗi đọc.

Dường như một trong các đĩa trong thiết lập nhân bản của tôi đã phát triển một khu vực xấu. Điều đó tự nó không đáng báo động; những điều như vậy xảy ra, và đó chính xác là lý do tại sao tôi có sự dư thừa (chính xác là gương hai chiều). Mỗi lần tôi xóa hồ bơi hoặc đọc qua các tệp trong một thư mục cụ thể (tôi vẫn chưa bận tâm để xác định chính xác tệp nào bị lỗi), các thông báo sau xuất hiện trong dmesg, rõ ràng là có dấu thời gian khác nhau:

Nov  1 09:54:26 yeono kernel: [302621.236549] ata6.00: exception Emask 0x0 SAct 0x9c10 SErr 0x0 action 0x0
Nov  1 09:54:26 yeono kernel: [302621.236557] ata6.00: irq_stat 0x40000008
Nov  1 09:54:26 yeono kernel: [302621.236566] ata6.00: failed command: READ FPDMA QUEUED
Nov  1 09:54:26 yeono kernel: [302621.236578] ata6.00: cmd 60/a8:78:18:5a:12/00:00:5c:01:00/40 tag 15 ncq 86016 in
Nov  1 09:54:26 yeono kernel: [302621.236580]          res 41/40:a8:18:5a:12/00:00:5c:01:00/00 Emask 0x409 (media error) <F>
Nov  1 09:54:26 yeono kernel: [302621.236585] ata6.00: status: { DRDY ERR }
Nov  1 09:54:26 yeono kernel: [302621.236589] ata6.00: error: { UNC }
Nov  1 09:54:26 yeono kernel: [302621.238214] ata6.00: configured for UDMA/133

Đây là một phiên bản Debian Wheezy khá cập nhật, kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Các phiên bản gói hiện có tại debian-zfs = 7 ~ wheezy, libzfs2 = 0.6.3-1 ~ wheezy, zfs-dkms = 0.6.3-1 ~ wheezy, zfs-initramfs = 0.6.3-1 ~ wheezy, zfsutils = 0.6 .3-1 ~ wheezy, zfsonlinux = 3 ~ wheezy, linux-image-amd64 = 3.2 + 46, linux-image-3.2.0-4-amd64 = 3.2.63-2. Gói ghim duy nhất mà tôi biết là dành cho ZoL, mà tôi có (như được cung cấp bởi gói zfsonlinux):

Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001

Chạy hdparm -Rtrên ổ đĩa báo cáo rằng Write-Read-Confirm được bật (đây là Seagate, tính năng đó cũng vậy và tôi sử dụng nó như một mạng an toàn bổ sung; độ trễ ghi bổ sung không phải là vấn đề vì mẫu sử dụng tương tác của tôi rất dễ đọc -nặng):

/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
 write-read-verify =  2

Ngay cả khi đưa ra dấu hiệu rõ ràng rằng có gì đó không ổn, zpool statustuyên bố rằng không có vấn đề gì với nhóm:

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 8h16m with 0 errors on Sat Nov  1 10:46:03 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        akita                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c50065e8414a  ONLINE       0     0     0
            wwn-0x5000c500645b0fec  ONLINE       0     0     0

errors: No known data errors

Lỗi này đã xuất hiện thường xuyên trong nhật ký trong vài ngày qua (kể từ ngày 27 tháng 10), vì vậy tôi không có khuynh hướng viết nó ra chỉ đơn thuần là một con sán. Tôi chạy các đĩa với thời gian chờ SCTERC khá ngắn; 1,5 giây đọc (để phục hồi nhanh chóng từ lỗi đọc), 10 giây ghi. Tôi đã xác nhận rằng các giá trị này đang hoạt động trên ổ đĩa được đề cập.

smartd tiếp tục làm phiền tôi (mà bản thân nó là một điều tốt!) về thực tế là số lỗi ATA đang tăng lên:

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX [SAT], ATA error count increased from 4 to 5

For details see host's SYSLOG.

Chạy smartctl --attributestrên ổ đĩa trong câu hỏi mang lại như sau:

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   076   063   044    Pre-fail  Always       -       48910012
  3 Spin_Up_Time            0x0003   091   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       97
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   030    Pre-fail  Always       -       1698336160
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       9887
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       98
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   095   095   000    Old_age   Always       -       5
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       10
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   045    Old_age   Always       -       42 (Min/Max 20/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       492
194 Temperature_Celsius     0x0022   042   048   000    Old_age   Always       -       42 (0 11 0 0)
195 Hardware_ECC_Recovered  0x001a   052   008   000    Old_age   Always       -       48910012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Không có gì hào nhoáng ngoài kia bình thường. Lưu ý rằng đây là ổ đĩa dành cho doanh nghiệp, do đó, bảo hành năm năm và được xếp hạng cho hoạt động 24x7 (có nghĩa là nó đáng tin cậy trong hơn 40.000 giờ hoạt động, so với chỉ dưới 10.000 giờ cho đến nay). Lưu ý số 5 trong thuộc tính 187 Báo cáo_ Không chính xác; đó là vấn đề. Cũng lưu ý các giá trị Start_Stop_Count và Power_Cycl_Count khá thấp dưới 100 mỗi giá trị.

Không phải tôi nghĩ nó có liên quan trong trường hợp này, nhưng đúng vậy, hệ thống có RAM ECC.

Các thuộc tính không mặc định của hệ thống tệp gốc trên nhóm là:

NAME   PROPERTY              VALUE                  SOURCE
akita  type                  filesystem             -
akita  creation              Thu Sep 12 18:03 2013  -
akita  used                  3,14T                  -
akita  available             434G                   -
akita  referenced            136K                   -
akita  compressratio         1.04x                  -
akita  mounted               no                     -
akita  mountpoint            none                   local
akita  version               5                      -
akita  utf8only              off                    -
akita  normalization         none                   -
akita  casesensitivity       sensitive              -
akita  usedbysnapshots       0                      -
akita  usedbydataset         136K                   -
akita  usedbychildren        3,14T                  -
akita  usedbyrefreservation  0                      -
akita  sync                  standard               local
akita  refcompressratio      1.00x                  -
akita  written               0                      -
akita  logicalused           2,32T                  -
akita  logicalreferenced     15K                    -

và tương ứng cho chính hồ bơi :

NAME   PROPERTY               VALUE                  SOURCE
akita  size                   3,62T                  -
akita  capacity               62%                    -
akita  health                 ONLINE                 -
akita  dedupratio             1.00x                  -
akita  free                   1,36T                  -
akita  allocated              2,27T                  -
akita  readonly               off                    -
akita  ashift                 12                     local
akita  expandsize             0                      -
akita  feature@async_destroy  enabled                local
akita  feature@empty_bpobj    active                 local
akita  feature@lz4_compress   active                 local

Những danh sách này có được bằng cách chạy {zfs,zpool} get all akita | grep -v default.

Bây giờ cho các câu hỏi:

1. Tại sao ZFS không báo cáo bất cứ điều gì về vấn đề đọc? Nó đang hồi phục rõ ràng từ nó.

2. Tại sao ZFS không tự động viết lại khu vực duff mà ổ đĩa rõ ràng đang gặp sự cố khi đọc, do đó hy vọng sẽ kích hoạt việc di chuyển bởi ổ đĩa, do có đủ dư thừa để sửa chữa tự động trong đường dẫn yêu cầu đọc?

Tôi nghi ngờ trình điều khiển ATA đang thử lại thao tác đọc một vài lần khi nó nhận được lỗi trước khi chuyển lỗi trở lại trình điều khiển hệ thống tập tin.

Điều này có nghĩa là vào thời điểm trình điều khiển hệ thống tập tin ZFS nhận được kết quả của việc đọc dữ liệu ở đó và chính xác, nhưng có thể mất nhiều thời gian hơn bình thường để xảy ra. Tất nhiên không có bộ đếm lỗi cho độ trễ cao hơn mức trung bình, vì vậy không có gì được ghi lại.

Thực tế là giá trị SMART cho Báo cáo_ Không chính xác không phải là 0 khiến tôi nghi ngờ rằng nguyên nhân của sự cố là do chính đĩa, trái ngược với việc nói rằng cáp SATA hoặc bộ điều khiển SATA bị bong ra.

Nếu đây là trường hợp, rất có thể đĩa cuối cùng sẽ chết nhiều hơn và bắt đầu không đọc được ngay cả khi nhiều lần thử lại trình điều khiển thiết bị khối đang cố gắng. Như vậy lời khuyên của tôi sẽ là thay thế đĩa.

Việc thử nghiệm một bài kiểm tra SMART dài có thể sẽ thất bại trên các khối bị ảnh hưởng, nếu bạn muốn làm cho lỗi biến mất việc viết lại các khối đó (ví dụ với dd) sẽ khiến đĩa hoán đổi các khu vực đó, nhưng theo kinh nghiệm của tôi là khi một ổ đĩa bắt đầu để đi tốt hơn là chỉ cần thay thế nó và được thực hiện với nó.

Tôi đã có một đĩa SCSI xấu với một cuộc đột kích ZFS trên Solaris. Tôi đã quét các tệp nhật ký để biết thông tin về các thông báo lỗi để thu thập bằng chứng đĩa bị hỏng và nhờ Oracle bảo vệ nó trong phần bảo trì phần cứng. Tôi đã chạy grep cho một số chuỗi nhất định trong nhật ký lỗi và những dòng này hiển thị lỗi đĩa sẽ nằm trong màn hình bảng điều khiển của tôi. Khi "Explorer" (công cụ báo cáo và nhật ký hệ thống cho Solaris) được chạy và gửi tới Oracle, họ nói rằng không có lỗi trên các đĩa. Nhưng tôi đã có chúng trên lịch sử màn hình của tôi. Tôi đã kiểm tra và nó thực sự đã đi từ các bản ghi trên đĩa.

Đây là những gì đang diễn ra ... ZFS hứa hẹn không có lỗi hệ thống tệp, không phải lỗi dữ liệu. Khi gặp phải một tham nhũng nghiêm trọng, nó sẽ khôi phục giao dịch, làm bất cứ điều gì được yêu cầu để làm cho tính toàn vẹn của hệ thống tệp tốt. Do đó, các cập nhật tệp bị mất khi quay lại phiên bản cũ hơn của tệp trước khi bị hỏng và do đó mất dữ liệu có thể xảy ra. Nhưng hệ thống tập tin của bạn không có lỗi.

Có lẽ đối với các lỗi đơn giản, ZFS có thể khôi phục và ghi lại dữ liệu trong một lần thử khác, nhưng có vẻ như trong các trường hợp nghiêm trọng về hành vi đĩa xấu, nó có thể bị kẹt trong 22 khi dữ liệu không được phục hồi và ghi. Nếu bạn cần thu thập bằng chứng về lỗi đĩa, hãy để chúng xuất hiện trên màn hình và không dựa vào bằng chứng sẽ nằm trên đĩa, nơi dữ liệu có khả năng được đặt lại bởi các giao dịch ZFS.