Я использую производную FreeNAS 9.3 для конкретного производителя.
Моя проблема началась, когда я установил новое шасси JBOD, чтобы добавить два новых vdev в свой пул, и у шасси была плохая плата. В это время я наблюдал ошибки питания SAS на дисках на плохой плате - мои новые диски эффективно включались и выключались снова, неоднократно, каждую минуту.
Я заменил плату, и теперь, по большинству показателей, диски работают нормально, но ZFS все еще выдает мне чрезвычайно странные ошибки контрольной суммы, когда я просматриваю zpool status. Я думаю, что были некоторые плохие записи CoW, когда у меня были проблемы с питанием SAS.
Первое шасси с ЦП, загрузочным диском, ОЗУ и т. Д. Подключается к первому шасси расширения JBOD через mini-SAS, а второе шасси расширения JBOD подключается в гирляндную цепь через первое шасси расширения JBOD, также через mini-SAS.
Ошибки контрольной суммы не точно соответствуют какому-либо одному контроллеру или шасси, но я догадываюсь, что, когда у меня были эти проблемы с питанием, любые данные, записываемые на разные новые диски, плохо записывались на двух новых vdev.
Мои HBA находятся на хорошей прошивке LSI - все 20.00.04.00 или 20.00.08.00
Я поменял местами кабели mini-SAS и безуспешно пытался использовать разные порты.
Выход zpool statusпоказывает ошибки контрольной суммы, накапливающиеся в двух новых vdev, и после очистки, перезагрузки или zpool clear, в конце концов zpool status отмечает эти vdevs как деградированные. Странно то, что он еще и маркирует некоторые дисков, принадлежащих этим vdev, как деградированных, но их фактическое количество ошибок на отдельных дисках равно 0. zdb показывает, что отдельные диски помечены как поврежденные, потому что у них слишком много ошибок контрольной суммы, хотя все их счетчики ошибок контрольной суммы фактически равны 0. Что еще странно, так это то, что ошибки контрольной суммы на уровне пула показывают меньшее число, чем ошибки контрольной суммы из двух проблем vdevs сложены вместе.
zpool status -v постоянно показывает постоянную ошибку в снимке, сопоставленном с 0x0 индексный дескриптор, который уже давно удален, но не может быть очищен многократной очисткой, перезагрузкой или zpool clear. Кроме того, появляются и исчезают другие постоянные ошибки, иногда они отображаются только как inodes шестнадцатеричного кода, а иногда как часть последних снимков. Я не могу найти 0x0 с участием lsof.
Я считаю, что может быть какое-то повреждение данных с метаданными в пуле.
Я ищу способ удалить эти фантомные снимки хирургическим путем или иным образом вернуть мой пул в работоспособное состояние без разрушения данных. Я подозреваю, что где-то ZFS перебирает эти поврежденные фантомные снимки и вызывает как причудливые ошибки контрольной суммы, так и ухудшенные состояния vdev.
У меня есть «холодные» резервные копии 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 на моем пуле как-нибудь "исправить" эти ошибки метаданных?
В 0x0 и другие шестнадцатеричные числа появляются вместо имен файлов и других объектов при повреждении метаданных. Если вы не можете избавиться от него, уничтожив затронутые объекты (я так понимаю, они относятся к снимкам), то, вероятно, повреждение слишком велико, чтобы его можно было исправить. В этом случае я бы восстановил пул из резервной копии, особенно если у вас есть дополнительные странные эффекты, такие как появление и исчезновение поврежденных метаданных.
О методах избавления от большинства проблем вы можете прочитать в Руководство администратора ZFS здесь. Но ZFS также дает вам URL-адрес для поиска решений при вводе zpool status.