Почему проверка ZFS не завершается?

Вопрос или проблема

Прежде всего, давайте начнем с того, что я использую. Это домашний медиасервер на Ubuntu 16.10. У меня есть один пул зеркальных 6-терабайтных дисков, которые заполнят примерно на половину. Я собрал систему около месяца назад, и она работает прекрасно. Он использует SSD в качестве загрузочного диска и вышеупомянутый пул в качестве хранилища. Я смог сделать все, что мне нужно, с этим пулом, и все выглядит отлично.

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

В данный момент я действительно пытаюсь просто запустить процесс проверки и безопасно отключить один диск от зеркала. Я запускаю

zpool scrub tank

и затем сразу запускаю

zpool status

и я вижу, как идет процесс проверки. Я могу запускать обновление каждые несколько секунд и видеть, как он обновляет статус без проблем. Он работает около 30 секунд, а затем статус больше не показывает, что он работает. Кроме того, я никогда не видел ничего, кроме последней проверки, завершенной за 0 часов 0 минут в статусе. Для меня это означает, что проверка не завершится, так как неужели проверка не должна занять как минимум несколько часов с двумя с половиной терабайтами информации для обработки.

Что я упускаю?


Добавление запрашиваемой информации:

  pool: Tank
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb  5 00:31:42 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb2    ONLINE       0     0     0
            sdc2    ONLINE       0     0     0

errors: No known data errors

Я снова пробую проверку, чтобы убедиться, что проблема все еще актуальна. Вот статус примерно через 20 секунд после начала…

  pool: Tank
 state: ONLINE
  scan: scrub in progress since Fri Feb 10 14:25:12 2017
    62.5M scanned out of 2.97T at 1.08M/s, (scan is slow, no estimated time)
    0 repaired, 0.00% done
config:

    NAME        STATE     READ WRITE CKSUM
    Tank        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb2    ONLINE       0     0     0
        sdc2    ONLINE       0     0     0

errors: No known data errors

и вот он снова через минуту…

  pool: Tank
 state: ONLINE
  scan: scrub repaired 0 in 0h1m with 0 errors on Fri Feb 10 14:27:01 2017
config:

    NAME        STATE     READ WRITE CKSUM
    Tank        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb2    ONLINE       0     0     0
        sdc2    ONLINE       0     0     0

errors: No known data errors

Правка для добавления информации 16/02/17

У меня заканчивается время, чтобы вернуть “шумный” диск, поэтому я его вытащил. Я ничего не делал, кроме как отключил его (когда система работала). Все продолжает правильно функционировать в данный момент, хотя и в состоянии DEGRADED, как и ожидалось. Я думаю, я продолжу документировать свой опыт здесь, поскольку я уже начал это делать. Похоже, никто другой не сталкивается с этой проблемой. Я не могу найти никого другого в интернете с такой же ситуацией. Мне повезло. Мы увидим, что произойдет, когда я получу заменяющий диск и снова запущу процесс проверки. Кто знает… может, боги данных будут милосердны ко мне, и простая замена диска заставит проблему решить саму себя. :/ Ниже мой вывод после отключения диска.

  pool: Tank
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: scrub repaired 0 in 0h1m with 0 errors on Sun Feb 12 00:24:38 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sdb2    ONLINE       0     0     0
            sdc2    UNAVAIL      0     0     0

errors: No known data errors

Правка для добавления информации 29/03/17

root@NAS:~# zpool status
  pool: Tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: resilvered 525M in 0h3m with 0 errors on Wed Mar 29 14:28:46 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb2    ONLINE       0     0     0
            sdc     ONLINE       0     0   732

errors: No known data errors

Может, еще одна подсказка о проблемах? посмотрите на раздел sdc…

root@NAS:/dev# parted --list
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system     Name                  Flags
 1      1049kB  538MB  537MB   fat32           EFI System Partition  boot, esp
 2      538MB   233GB  232GB   ext4
 3      233GB   250GB  17.1GB  linux-swap(v1)


Warning: Not all of the space available to /dev/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 7 blocks) or continue with the
current setting?
Fix/Ignore? i
Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdb: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      2097kB  2150MB  2147MB
 2      2150MB  6001GB  5999GB  zfs


Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdc: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  6001GB  6001GB  zfs          zfs-802af6a53a6d8383
 9      6001GB  6001GB  8389kB

Правка для добавления информации 13/04/17

Да, я пытаюсь решить эту проблему несколько месяцев :/

Во-первых, после экспорта/импорта буквы дисков изменились, поэтому учтите, что sdb стал sdc, а sdc стал sdd.

Я думаю, я нашел проблему, и хочу получить совет, как ее исправить. Проблема была наконец обнаружена, когда я запустил “sudo fdisk -l”. Ниже приведены соответствующие фрагменты…

Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7127FE7D-E061-11E6-BD1F-3497F600DDAF

 Device     Start        End       Sectors    Size    Type
/dev/sdc1   4096       4198399     4194304     2G     FreeBSD swap
/dev/sdc2  4198400   11721043967 11716845568  5.5T    FreeBSD ZFS

...

Disk /dev/sdd: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E799A1D5-F9B7-C843-AB62-AADC9B0A2180

Device        Start           End         Sectors    Size    Type
/dev/sdd1      2048       11721027583   11721025536  5.5T    Solaris /usr & Apple ZFS
/dev/sdd9  11721027584    11721043967      16384      8M     Solaris reserved 1

Обратите внимание на это: зеркало изначально было создано в FreeNAS (FreeBSD). У sdc есть 2 ГБ подкачки в начале диска. sdd был создан в Ubuntu, и по какой-то причине ему был дан 8 МБ подкачки в конце диска.

Теперь, опасаясь, что проблема в неисправном диске, я отключил sdd и запустил badblocks на нем. Это стирает всю информацию. Хорошая новость в том, что диск в порядке, нет плохих секторов. Это также сбрасывает разделы на ноль.

У меня есть два варианта. 1.) Попробовать вручную сопоставить разделы sdd с рабочим диском (sdc). Хотя я думал, что zfs должен делать это автоматически, просто запустив zpool replace, поэтому, возможно, это пустая трата времени. 2.) У меня есть данные на резервной копии, так что я мог бы очистить оба диска и начать с нуля, создать новое зеркало и сделать его нативным пулом Ubuntu.

Может быть, это чрезмерное размышление, но я думаю, что я рискую больше, разрушая и восстанавливая. Мне нужно уничтожить хорошие данные, которые только на резервной копии на нерезервированном диске, а затем снова rsync их обратно в вновь созданный пул. К вашему сведению, я использовал rsync для создания резервной копии, и она на том же ПК. Мне пришлось объединить 3 диска без избыточности, чтобы уместить все данные. Я также боюсь, что перемещение данных таким образом без возможности проверить это может привести к повреждению, и я никогда не узнаю.

У кого-нибудь есть советы? Спасибо!

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

Во-первых, проверьте dmesg на предмет ошибок:

dmesg | grep -i zfs

Затем экспортируйте и импортируйте пул:

zpool export Tank
zpool import Tank

Убедитесь, что оба диска используют одну и ту же схему разделов. Исправьте разделы на sdc, чтобы они соответствовали sdb:

parted /dev/sdc -- mklabel gpt
parted /dev/sdc -- mkpart primary 2150MB 100%

Замените диск:

zpool replace Tank <old_drive> <new_drive>

Запустите повторную проверку пула:

zpool scrub Tank

В качестве альтернативы, вы можете создать новый пул на замещающем диске и передать данные:

zpool create NewPool mirror /dev/sdd
zfs send -R Tank | zfs receive -F NewPool

Спасибо!

Ответ или решение

Проблема несовершенной работы процесса сканирования (scrub) в ZFS может быть вызвана рядом факторов, связанных с конфигурацией ваших дисков и состоянием пула. Рассмотрим детально возможные причины и шаги по устранению проблемы.

1. Неурегулированные разделы дисков

Одной из основных причин проблемы является несоответствие разметки разделов на дисках в зеркале. В вашем случае один из дисков (sdc) имеет раздел под своп (FreeBSD swap), в то время как другой (sdd) использует только ZFS. Это может вызвать ошибки при выполнении операций с пулом, включая сканирование.

Решение: Вам необходимо убедиться, что разделы обоих дисков идентичны. Для этого вы можете использовать команду parted для корректировки разметки:

parted /dev/sdc -- mklabel gpt
parted /dev/sdc -- mkpart primary 2150MB 100%

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

2. Ошибки ядра и ZFS

Чтобы выявить дополнительные проблемы, стоит проверить системные логи на наличие ошибок, связанных с ZFS. Это можно сделать с помощью команды:

dmesg | grep -i zfs

Логи могут содержать подсказки о том, какие проблемы могут мешать успешному завершению операции scrub.

3. Экспорт и импорт пула

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

zpool export Tank

А затем импортировать:

zpool import Tank

4. Замена проблемного диска

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

zpool replace Tank /dev/sdc /dev/sdd

Где /dev/sdc — это старый проблемный диск, а /dev/sdd — новый диск. После этой операции ZFS начнет процесс восстановления (resilver) данных на новом диске.

5. Пересоздание пула

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

zpool create NewPool mirror /dev/sdX /dev/sdY

После чего вы можете использовать команды zfs send и zfs receive для передачи данных из старого пула в новый:

zfs send -R Tank | zfs receive -F NewPool

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...