У меня создалось впечатление, что если во время чтения из пула ZFS произойдет ошибка ввода-вывода, произойдут две вещи:
Похоже, что на одном из дисков в моей настройке зеркала образовался сбойный сектор. Само по себе это не вызывает беспокойства; такое бывает, и именно поэтому у меня есть избыточность (точнее двустороннее зеркало). Каждый раз, когда я очищаю пул или просматриваю файлы в определенном каталоге (я еще не удосужился определить, в каком именно файле произошла ошибка), в 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 на диске сообщает, что запись-чтение-проверка включена (это Seagate, поэтому у меня есть эта функция, и я использую ее в качестве дополнительной подстраховки; дополнительная задержка записи не является проблемой, поскольку мой интерактивный шаблон использования очень удобен для чтения - тяжелый):
/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.
Нестандартные свойства корня файловая система на бассейне находятся:
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.
А теперь вопросы:
Почему нет ZFS сообщить что-нибудь о проблеме чтения? Он явно восстанавливается после этого.
Почему ZFS не перезаписывает автоматически сектор duff, который диск явно не читает, что в свою очередь, мы надеемся, запускает перемещение диска, учитывая, что существует достаточная избыточность для автоматического восстановления в пути запроса чтения?
Я подозреваю, что драйвер ATA несколько раз повторяет операцию чтения, когда получает сообщение об ошибке, прежде чем передать ошибку обратно драйверу файловой системы.
Это означает, что к тому времени, когда драйвер файловой системы ZFS получит результат чтения, все данные будут там и верны, но, вероятно, это заняло немного больше времени, чем обычно. Конечно, нет счетчика ошибок для задержки выше среднего, поэтому ничего не регистрируется.
Тот факт, что значение SMART для Reported_Uncorrect не равно 0, заставляет меня подозревать, что причиной сбоя является сам диск, в отличие от того, что кабель SATA или контроллер SATA нестабильны.
В этом случае, скорее всего, диск со временем еще больше перестанет работать и начнет не читать даже после того, как много попыток пытается выполнить драйвер блочного устройства. Поэтому я бы посоветовал заменить диск.
Запуск длительного теста SMART, скорее всего, не удастся для затронутых блоков, если вы хотите, чтобы ошибка исчезла, перезапись этих блоков (например, с помощью dd) должна привести к тому, что диск поменяет эти секторы, но, по моему опыту, когда диск запускается чтобы пойти, лучше просто заменить его и покончить с этим.
У меня был плохой SCSI-диск с рейдом ZFS на Solaris. Я просматривал файлы журналов в поисках информации об ошибках, чтобы собрать доказательства того, что диск неисправен, и попросить Oracle покрыть его обслуживанием оборудования. Я запустил grep для определенных строк в журналах ошибок, и эти строки, показывающие ошибки диска, будут на моем экране консоли. Когда "Explorer" (системный журнал и инструмент отчетности для Solaris) был запущен и отправлен в Oracle, они сказали, что на дисках нет ошибок. Но они у меня были в истории экрана. Я проверил, и он действительно исчез из журналов на диске.
Вот что происходило ... ZFS обещает ноль ошибок файловой системы, а не ноль ошибок данных. Когда обнаруживается серьезное повреждение, он откатывает транзакцию, делая все необходимое для обеспечения целостности файловой системы. В результате обновления файла теряются при откате к более ранней версии файла до повреждения, и, следовательно, может произойти потеря данных. Но ваша файловая система не содержит ошибок.
Возможно, для простых ошибок ZFS может откатиться и перезаписать данные в другой попытке, но кажется, что в серьезных случаях плохого поведения диска он может попасть в ловушку-22, когда данные не восстанавливаются и не записываются. Если вам нужно собрать доказательства ошибок диска, сделайте так, чтобы они появлялись на экране, и не полагайтесь на доказательства, которые будут находиться на диске, где данные потенциально сбрасываются в результате откатов транзакций ZFS.