Почему ZFS ничего не делает с сектором duff моего диска?

У меня сложилось впечатление, что если во время чтения из пула ZFS произойдет ошибка ввода-вывода, произойдут две вещи:

1. Ошибка будет записана либо в статистику READ, либо в CKSUM соответствующего устройства с распространением вверх к уровню пула.
2. • Избыточные данные будут использоваться для восстановления запрошенного блока, возврата запрашиваемого блока вызывающей стороне и, если накопитель Duff все еще работает, переписать в него блок ИЛИ
   • Ошибка ввода-вывода будет возвращена, если избыточные данные недоступны для исправления ошибки чтения.

Похоже, что один из дисков в моей настройке зеркала имеет плохой сектор. Это само по себе не вызывает тревоги; такие вещи случаются, и именно поэтому у меня есть избыточность (двустороннее зеркало, если быть точным). Каждый раз, когда я очищаю пул или читаю файлы в определенном каталоге (я пока не удосужился точно определить, в каком файле произошла ошибка), в dmesg появляется следующее сообщение, очевидно, с разными временными метками:

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

Это довольно актуальный Debian Wheezy, ядро ​​3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Версии пакета действительны: 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. Единственный известный мне пакет - это ZoL, для которого у меня есть (как это предусмотрено пакетом zfsonlinux):

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

Работа hdparm -Rна накопителе сообщает о том, что Write-Read-Verify включен (это Seagate, поэтому имеет эту функцию, и я использую ее в качестве дополнительной защитной сети; дополнительная задержка записи не является проблемой, поскольку мой шаблон интерактивного использования очень читается -heavy):

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

Даже учитывая четкое указание на то, что что-то не так, zpool statusутверждает, что с пулом проблем нет:

  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

Эта ошибка регулярно появлялась в журналах в течение последних нескольких дней (с 27 октября), поэтому я не очень склонен списывать ее на случайность. Я запускаю диски с довольно короткими тайм-аутами SCTERC; 1,5 секунды чтения (для быстрого восстановления после ошибок чтения), 10 секунд записи. Я подтвердил, что эти значения активны на данном диске.

SmartD продолжает приставать ко мне (что само по себе хорошо!) по поводу того, что количество ошибок ATA растет:

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.

Работа smartctl --attributesна данном диске дает следующее:

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

Ничего вопиюще необычного там. Обратите внимание, что это корпоративный накопитель, поэтому он имеет пятилетнюю гарантию и рассчитан на работу в режиме 24x7 (это означает, что он рассчитан на более 40 000 часов работы по сравнению с чуть менее 10 000 часов на данный момент). Обратите внимание на число 5 в атрибуте 187 Reported_Uncorrect; вот в чем проблема. Также обратите внимание на довольно низкие значения Start_Stop_Count и Power_Cycle_Count - до 100 каждый.

Не то чтобы я думаю, что это уместно в этом случае, но да, система имеет ECC RAM.

Свойства по умолчанию корневой файловой системы в пуле:

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                    -

и соответственно для самого бассейна :

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

Эти списки были получены путем запуска {zfs,zpool} get all akita | grep -v default.

Теперь по вопросам:

1. Почему ZFS ничего не сообщает о проблеме чтения? Это явно оправляется от этого.

2. Почему ZFS не перезаписывает автоматически сектор duff, из-за которого у диска явно возникают проблемы с чтением, в свою очередь, мы надеемся, что это приведет к перемещению диска, учитывая, что существует достаточная избыточность для автоматического восстановления в пути запроса на чтение?

Я подозреваю, что драйвер ATA повторяет операцию чтения несколько раз, когда он получает ошибку, прежде чем передать ошибку обратно в драйвер файловой системы.

Это означает, что к тому моменту, когда драйвер файловой системы ZFS получит результат чтения, все данные будут исправлены, но, скорее всего, это займет немного больше времени, чем обычно. Конечно, для задержки выше среднего счетчик ошибок отсутствует, поэтому ничего не регистрируется.

Тот факт, что значение SMART для Reported_Uncorrect не равно 0, заставляет меня подозревать, что причиной сбоя является сам диск, в отличие от того, что кабель SATA или контроллер SATA являются ненадежными.

Если это так, то, скорее всего, диск в конечном итоге умрет еще больше и не сможет прочитать даже после того, как много попыток попытается драйвер блочного устройства. Таким образом, мой совет будет заменить диск.

Выполнение длинного SMART-теста, скорее всего, приведет к сбою на задействованных блоках, если вы хотите, чтобы ошибка исчезла, перезапись этих блоков (например, с помощью dd) должна привести к замене этих секторов на диске, но, по моему опыту, когда диск запускается чтобы идти, лучше просто заменить его и покончить с этим.

У меня был плохой диск SCSI с рейдом ZFS на Solaris. Я сканировал файлы журналов для получения информации о сообщениях об ошибках, чтобы собрать доказательства того, что диск был неисправен, и получить Oracle, чтобы покрыть это на обслуживании оборудования. Я запустил grep для определенных строк в журналах ошибок, и эти строки, показывающие ошибки диска, будут на моем экране консоли. Когда «Explorer» (системный журнал и средство отчетности для Solaris) был запущен и отправлен в Oracle, они сказали, что на дисках не было ошибок. Но у меня были они на моей истории экрана. Я проверил, и это действительно пропало из журналов на диске.

Вот что происходит ... ZFS обещает ноль ошибок файловой системы, а не ноль ошибок данных. Когда происходит серьезное повреждение, он откатывает транзакцию, делая все необходимое для обеспечения целостности файловой системы. В результате обновления файла теряются при его откате к более ранней версии файла до повреждения, и, следовательно, может произойти потеря данных. Но ваша файловая система не содержит ошибок.

Возможно, из-за простых ошибок ZFS может выполнить откат и перезапись данных в другой попытке, но в серьезных случаях плохого поведения диска это может оказаться в ловушке, когда данные не восстанавливаются и не записываются. Если вам нужно собрать свидетельства об ошибках диска, заставьте их появиться на экране и не полагайтесь на доказательства, которые будут находиться на диске, где данные могут быть сброшены при откате транзакций ZFS.