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

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

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

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

Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси расширения JBOD через mini-SAS, а второе шасси расширения JBOD последовательно соединяется через первое шасси расширения JBOD, также через мини-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]

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

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

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

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

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

Я полагаю, что метаданные в пуле могут повредить данные.

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

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

Вот вывод 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 я попытался скопировать System dataset pool от pool к freenas-boot а затем попытался с помощью zfs destroy удалить pool копия pool/.system и оставив freenas-boot копия не повреждена. Я был в состоянии использовать zfs destroy удалить все внутри pool/.system перечислены в zfs list, но при попытке уничтожить pool/.system с zfs destroy оболочка вернула ошибку: Cannot iterate filesystems: I/O error, Я старался zfs destroy на pool/.system с -f, -r, а также -R флаги, согласно документации Oracle ZFS, безрезультатно.

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

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

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

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

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