ZFS vdevs накапливает ошибки контрольной суммы, но отдельные диски нет.

Я использую производную FreeNAS 9.3 для конкретного производителя.

Моя проблема началась, когда я установил новое шасси JBOD, чтобы добавить два новых vdev в свой пул, и у шасси была плохая плата. В это время я наблюдал ошибки питания SAS на дисках на плохой плате - мои новые диски эффективно включались и выключались снова, многократно, каждую минуту.

Я заменил плату, и теперь, по большинству мер, диски работают нормально, но ZFS по-прежнему выдает мне очень странные ошибки контрольной суммы, когда я просматриваю статус zpool . Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси JBOD расширения через mini-SAS, а второе Шасси расширения JBOD подключается гирляндой через первое шасси расширения JBOD, а также через mini-SAS.

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

Я заменил плату, и теперь, по большинству показателей, диски работают нормально. , но ZFS все еще выдает очень странные ошибки контрольной суммы, когда я просматриваю статус zpool . Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси JBOD расширения через mini-SAS, а второе Шасси расширения JBOD подключается гирляндой через первое шасси расширения JBOD, а также через mini-SAS.

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

Я заменил плату, и теперь, по большинству показателей, диски работают нормально. , но ZFS по-прежнему выдает очень странные ошибки контрольной суммы, когда я просматриваю zpool status . Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси JBOD расширения через mini-SAS, а второе Шасси расширения JBOD подключено гирляндной цепочкой через первое шасси расширения JBOD, а также через mini-SAS.

но ZFS по-прежнему выдает мне очень странные ошибки контрольной суммы, когда я просматриваю zpool status . Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси JBOD расширения через mini-SAS, а второе Шасси расширения JBOD подключено гирляндной цепочкой через первое шасси расширения JBOD, а также через mini-SAS.

но ZFS все еще выдает очень странные ошибки контрольной суммы, когда я просматриваю статус zpool . Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси JBOD расширения через mini-SAS, а второе Шасси расширения JBOD подключено гирляндной цепочкой через первое шасси расширения JBOD, а также через mini-SAS.

• [Шасси 1: загрузочный диск, два твердотельных накопителя L2ARC, 11/11 дисков RAIDZ3-0, 1/11 дисков RAIDZ3-1] -> mini-SAS для шасси 2
• [Шасси 2: 10/11 приводов RAID Z3-1, 6/11 дисков RAID Z3-2] -> mini-SAS для шасси 3
• [Шасси 3: 5/11 дисков RAIDZ3-2, 11/11 дисков RAIDZ3-3]

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

Мои HBA находятся на хорошей прошивке LSI - все они находятся на 20.00.04.00 или 20.00.08.00

Я поменял местами кабели mini-SAS и попытался использовать разные порты, но безрезультатно.

Вывод zpool status показывает ошибки контрольной суммы, накапливающиеся в двух новых vdev, и после любого из них scrub , перезагрузка или zpool clear , в конечном итоге zpool status помечает эти vdev как устаревшие. Какой' Странно то, что он также отмечает некоторые приводов, принадлежащих этим vdev, как поврежденные, но их фактическое количество ошибок на отдельных дисках равно 0. zdb показывает, что отдельные диски помечены как деградированные, потому что у них слишком много ошибок контрольной суммы, хотя все их счетчики ошибок контрольной суммы на самом деле равны 0. Что еще странно, так это то, что ошибки контрольной суммы на уровне пула показывают меньшее число, чем ошибки контрольной суммы из двух проблемных vdev, сложенных вместе.

zpool status -v постоянно показывает постоянную ошибку в моментальном снимке, сопоставленном с индексным дескриптором 0x0 , который уже давно удален, но не может быть очищен многократной очисткой, перезагрузкой или zpool clear . Кроме того, появляются и исчезают другие постоянные ошибки, иногда отображаемые только как inodes шестнадцатеричного кода, а в других случаях как часть недавних снимков. Я не могу найти 0x0 с lsof .

Я полагаю, что может быть какое-то повреждение данных с метаданными в пуле.

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

У меня есть «холодные» резервные копии LTO большей части моих важных данных, но в противном случае, если я не могу восстановить свой пул, я готовлюсь к установке второго сервера, выгрузить все на «горячий» второй сервер, уничтожить мой пул на верхнем уровне, а затем перезагрузить из горячего резервного копирования.

Вот ' s вывод команды zpool status -v :

[root@Jupiter] ~# zpool status -v
  pool: freenas-boot
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool.
  scan: resilvered 944M in 0h17m with 0 errors on Tue Aug  9 11:56:28 2016
config:

    NAME        STATE     READ WRITE CKSUM
    freenas-boot  ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        da46p2  ONLINE       0     0     0  block size: 8192B configured, 8388608B native
        da47p2  ONLINE       0     0     0  block size: 8192B configured, 8388608B native

errors: No known data errors

  pool: pool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub in progress since Fri Sep  9 22:43:51 2016
        6.27T scanned out of 145T at 1.11G/s, 35h27m to go
        0 repaired, 4.33% done
config:

    NAME                                            STATE     READ WRITE CKSUM
    pool                                            DEGRADED     0     0   118
      raidz3-0                                      ONLINE       0     0     0
        gptid/ac108605-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ac591d4e-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ac92fd0d-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/accd3076-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad067e97-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad46cbee-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad91ba17-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/adcbdd0a-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae07dc0d-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae494d10-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae93a3a5-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
      raidz3-1                                      ONLINE       0     0     0
        gptid/12f6a4c5-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/511ea1f9-1932-11e6-9b1e-0cc47a599098  ONLINE       0     0     0
        gptid/14436fcf-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/14f50aa3-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/159b5654-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/163d682b-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/16ee624e-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/1799dde3-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/184c2ea4-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/18f51c30-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/19a861ea-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
      raidz3-2                                      DEGRADED     0     0   236
        gptid/5f80fc42-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/60369e0f-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/60e8234a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/61a235f2-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/62580471-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/6316a38a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/63d4bce8-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/ebfc2b99-6893-11e6-9b09-0cc47a599098  ONLINE       0     0     0
        gptid/654f143a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/66236b33-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/66eda3f6-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
      raidz3-3                                      DEGRADED     0     0   176
        gptid/c77a9da9-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/c83e100e-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/c8fd9ced-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/c9bb21ba-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/ca7a48db-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/cb422329-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/cbfe4c21-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/ccc43528-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/cd93a34c-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/ce622f51-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/cf2591d3-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
    cache
      gptid/aedd3872-265c-11e5-9a02-0cc47a599098    ONLINE       0     0     0
      gptid/af559c10-265c-11e5-9a02-0cc47a599098    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        <0x357>:<0x2aef3>
        <0x37b>:<0x397285>
pool/.system@auto-20160720.2300-2d:<0x0>

Через графический интерфейс FreeNAS я попытался скопировать системный пул наборов данных из пула в freenas -boot , а затем попытался использовать zfs destroy , чтобы удалить пул копию pool / .system и оставить freenas-boot копия без изменений. Я смог использовать zfs destroy , чтобы удалить все в пуле / .system , перечисленных в zfs list , но при попытке уничтожить пул /.system с zfs destroy , оболочка вернула ошибку: Невозможно выполнить итерацию файловых систем: ошибка ввода-вывода . Я пробовал zfs destroy на pool /. system с флагами -f , -r и -R согласно документации Oracle ZFS , чтобы безрезультатно.

Я начал еще одну чистку. Возможно, удаление содержимого pool / .system в pool копии пула системного набора данных позволит очистителю удалить ошибку метаданных с помощью фантомного снимка бассейн /.system@auto-20160720.2300-2d.

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

После отключения моих периодических задач создания снимков и удаления всех снимков я попытался стереть один диск, а затем перенастроить его, но три диска, которые я уже восстановил, снова начали переносить. Теперь я почти уверен, что у меня будет два разных диска для каждой проблемной версии RAID-Z3 vdev, которая будет повторно обновляться, поэтому, если я попытаюсь восстановить еще какие-либо диски, я потеряю избыточность в каждом из проблемных vdevs и моем пуле приведет к ошибке.

Еще одно странное поведение заключается в том, что проверка zpool status -v фактически увеличивает счетчик ошибок контрольной суммы пула постепенно, а проверка zpool status - нет. Это похоже на то, как если бы сам флаг -v повторял любой механизм, вызывающий ошибки контрольной суммы.

Может ли использование zdb -c в моем пуле каким-либо образом «исправить» эти ошибки метаданных?