Почему при перезагрузке одна из сторон моего зеркала ZFS стала UNAVAIL?


13

Недавно я перенес пул хранения больших объемов данных (ZFS В Linux 0.6.2, Debian Wheezy) из конфигурации vdev для одного устройства в конфигурацию двустороннего зеркала vdev.

Предыдущая конфигурация пула была:

    NAME                     STATE     READ WRITE CKSUM
    akita                    ONLINE       0     0     0
      ST4000NM0033-Z1Z1A0LQ  ONLINE       0     0     0

Все было в порядке после завершения переноса (я запустил очистку после завершения переноса, просто чтобы система еще раз проверила все и проверила, все ли хорошо):

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 6h26m with 0 errors on Sat May 17 06:16:06 2014
config:

        NAME                       STATE     READ WRITE CKSUM
        akita                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            ST4000NM0033-Z1Z1A0LQ  ONLINE       0     0     0
            ST4000NM0033-Z1Z333ZA  ONLINE       0     0     0

errors: No known data errors

Тем не менее, после перезагрузки я получил электронное письмо с уведомлением о том, что пул не был в порядке и денди. Я посмотрел, и вот что я увидел:

   pool: akita
  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 in progress since Sat May 17 14:20:15 2014
     316G scanned out of 1,80T at 77,5M/s, 5h36m to go
     0 repaired, 17,17% done
 config:

         NAME                       STATE     READ WRITE CKSUM
         akita                      DEGRADED     0     0     0
           mirror-0                 DEGRADED     0     0     0
             ST4000NM0033-Z1Z1A0LQ  ONLINE       0     0     0
             ST4000NM0033-Z1Z333ZA  UNAVAIL      0     0     0

 errors: No known data errors

Скраб ожидается; есть настройка задания cron для запуска полной очистки системы при перезагрузке. Тем не менее, я определенно не ожидал, что новый жесткий диск выпадет из зеркала.

Я определяю псевдонимы, которые сопоставляются с именами / dev / disk / by-id / wwn- *, и в случае, если оба диска предоставили ZFS бесплатное управление для использования полного диска, включая обработку разметки:

# zpool history akita | grep ST4000NM0033
2013-09-12.18:03:06 zpool create -f -o ashift=12 -o autoreplace=off -m none akita ST4000NM0033-Z1Z1A0LQ
2014-05-15.15:30:59 zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ ST4000NM0033-Z1Z333ZA
# 

Это соответствующие строки из /etc/zfs/vdev_id.conf (теперь я замечаю, что Z1Z333ZA использует символ табуляции для разделения, тогда как строка Z1Z1A0LQ использует только пробелы, но я, честно говоря, не понимаю, как это может быть уместно здесь) :

alias ST4000NM0033-Z1Z1A0LQ             /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA     /dev/disk/by-id/wwn-0x5000c50065e8414a

Когда я посмотрел, /dev/disk/by-id/wwn-0x5000c50065e8414a*были там, как и ожидалось, но /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*не были.

В sudo udevadm triggerрезультате появления символических ссылок в / dev / disk / by-vdev. Тем не менее, ZFS, похоже, не просто понимает, что они есть (Z1Z333ZA по-прежнему показывает как UNAVAIL). Этого, я полагаю, можно ожидать.

Я попытался заменить соответствующее устройство, но мне не повезло:

# zpool replace akita ST4000NM0033-Z1Z333ZA
invalid vdev specification
use '-f' to override the following errors:
/dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA-part1 is part of active pool 'akita'
# 

Оба диска обнаруживаются во время процесса загрузки (вывод журнала dmesg с указанием соответствующих дисков):

[    2.936065] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.936137] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.937446] ata4.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[    2.937453] ata4.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    2.938516] ata4.00: configured for UDMA/133
[    2.992080] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.104533] ata6.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[    3.104540] ata6.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    3.105584] ata6.00: configured for UDMA/133
[    3.105792] scsi 5:0:0:0: Direct-Access     ATA      ST4000NM0033-9ZM SN03 PQ: 0 ANSI: 5
[    3.121245] sd 3:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[    3.121372] sd 3:0:0:0: [sdb] Write Protect is off
[    3.121379] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    3.121426] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.122070] sd 5:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[    3.122176] sd 5:0:0:0: [sdc] Write Protect is off
[    3.122183] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    3.122235] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Оба диска подключены непосредственно к материнской плате; нет встроенного контроллера.

Импульсно я сделал:

# zpool online akita ST4000NM0033-Z1Z333ZA

который, кажется, работал; Z1Z333ZA теперь, по крайней мере, ONLINEи серебро. Приблизительно через час после пересадки он сканирует 180G и повторно обрабатывает 24G с выполнением 9,77%, что указывает на то, что он не выполняет полное восстановление, а скорее передает только дельту набора данных.

Я, честно говоря, не уверен, связана ли эта проблема с ZFS в Linux или с udev (пахнет немного как udev, но тогда почему один диск будет обнаружен нормально, а другой нет), но мой вопрос: как мне сделать уверен, что то же самое не повторится при следующей перезагрузке?

Я буду рад предоставить больше данных о настройке при необходимости; просто дай мне знать, что нужно.

Ответы:


10

Это проблема udev, характерная для вариантов Debian и Ubuntu . Большая часть моей ZFS на Linux работает с CentOS / RHEL.

Подобные темы в списке обсуждения ZFS упоминали об этом.

См.
Записи scsi и ata для одного и того же жесткого диска в / dev / disk / by-id
и
ZFS в Linux / Ubuntu: помощь в импорте zpool после обновления Ubuntu с 13.04 до 13.10, идентификаторы устройств изменены

Я не уверен, какой подход наиболее детерминированного пула устройств для систем Debian / Ubuntu. Для RHEL я предпочитаю использовать WWN устройства на устройствах общего пула. Но в других случаях полезно использовать имя устройства / серийный номер. Но udev должен иметь возможность держать все это под контролем.

# zpool status
  pool: vol1
 state: ONLINE
  scan: scrub repaired 0 in 0h32m with 0 errors on Sun Feb 16 17:34:42 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        vol1                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x500000e014609480  ONLINE       0     0     0
            wwn-0x500000e0146097d0  ONLINE       0     0     0
          mirror-1                  ONLINE       0     0     0
            wwn-0x500000e0146090c0  ONLINE       0     0     0
            wwn-0x500000e01460fd60  ONLINE       0     0     0

1
После перехода к пустым wwn-*именам пул выглядит стабильным.
CVn

1
@ MichaelKjörling, не могли бы вы рассказать, как вы перешли на wwn- * имена?
codecowboy

1
@codecowboy Ничего особенного. zpool detach akita ST4000NM0033-Z1Z333ZAзатем zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414aзатем zpool detach akita ST4000NM0033-Z1Z1A0LQзатем zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, проверяя после каждого шага , что пул был стабильным. Я настоятельно рекомендую сначала тщательно вычистить. С этим можно было бы и сойти с рук, zpool replaceно поскольку псевдонимы указывали на имена wwn, а у меня была избыточность плюс резервные копии, это было безопаснее. Прошло несколько дней, но я не спешил.
CVn
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.