Dlaczego ponowne uruchomienie spowodowało, że jedna strona mojego lustra ZFS stała się UNAVAIL?

13

Niedawno przeprowadziłem migrację puli pamięci masowej danych (ZFS w systemie Linux 0.6.2, Debian Wheezy) z konfiguracji vdev na jednym urządzeniu do dwukierunkowej konfiguracji vdev dublowania.

Poprzednia konfiguracja puli to:

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

Po zakończeniu resilvera wszystko było w porządku (zainicjowałem szorowanie po zakończeniu resilvera, aby system przejrzał wszystko ponownie i upewnił się, że wszystko jest w porządku):

  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

Jednak po ponownym uruchomieniu dostałem wiadomość e-mail z powiadomieniem o tym, że pula nie była w porządku i elegancka. Spojrzałem i oto co zobaczyłem:

   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

Oczekiwany jest peeling; istnieje konfiguracja zadania cron, aby zainicjować pełne czyszczenie systemu podczas ponownego uruchamiania. Jednak zdecydowanie nie spodziewałem się, że nowy dysk twardy wypadnie z lustra.

Definiuję aliasy odwzorowujące na nazwy / dev / disk / by-id / wwn- *, a w przypadku obu tych dysków ZFS może swobodnie korzystać z pełnego dysku, w tym obsługi partycjonowania:

# 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
# 

Są to odpowiednie wiersze z /etc/zfs/vdev_id.conf (teraz zauważam, że Z1Z333ZA używa znaku tabulacji do separacji, podczas gdy linia Z1Z1A0LQ używa tylko spacji, ale szczerze mówiąc, nie rozumiem, jak to może być istotne tutaj) :

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

Kiedy spojrzałem, /dev/disk/by-id/wwn-0x5000c50065e8414a*były tam zgodnie z oczekiwaniami, ale /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*nie były.

Wystąpienie sudo udevadm triggerspowodowało pojawienie się dowiązań symbolicznych w / dev / disk / by-vdev. Jednak ZFS zdaje się nie zdawać sobie sprawy, że tam są (Z1Z333ZA wciąż pokazuje jako UNAVAIL). Podejrzewam, że tyle można się spodziewać.

Próbowałem wymienić odpowiednie urządzenie, ale nie miałem szczęścia:

# 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'
# 

Oba dyski są wykrywane podczas procesu rozruchu (dane wyjściowe dziennika dmesg pokazujące odpowiednie dyski):

[    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

Oba dyski są podłączone bezpośrednio do płyty głównej; nie jest zaangażowany kontroler zewnętrzny.

Pod wpływem impulsu:

# zpool online akita ST4000NM0033-Z1Z333ZA

który wydaje się działać; Z1Z333ZA jest teraz przynajmniej ONLINEsprężysty. Około godziny do resilvera skanuje 180G i przeskalowuje 24G z wykonaniem 9,77%, co wskazuje, że nie robi pełnego resilvera, a jedynie przenosi deltę zestawu danych.

Naprawdę nie jestem pewien, czy ten problem dotyczy ZFS w systemie Linux, czy udev (pachnie trochę jak udev, ale dlaczego miałby być wykrywany jeden dysk w porządku, ale nie drugi), ale moje pytanie brzmi: jak to zrobić? na pewno to samo nie powtórzy się przy następnym restarcie?

W razie potrzeby chętnie podam więcej danych dotyczących konfiguracji; daj mi znać, co jest potrzebne.

CVn
źródło

Odpowiedzi:

10

Jest to problem udev, który wydaje się być specyficzny dla wariantów Debiana i Ubuntu . Większość mojej pracy nad ZFS w Linuksie dotyczy CentOS / RHEL.

Podobne wątki na liście dyskusyjnej ZFS wspominały o tym.

Zobacz:
wpisy scsi i ata dla tego samego dysku twardego w katalogu / dev / disk / by-id
i
ZFS w Linux / Ubuntu: Pomóż w importowaniu zpool po aktualizacji Ubuntu z 13.04 do 13.10, identyfikatory urządzeń uległy zmianie

Nie jestem pewien, jakie jest najbardziej deterministyczne podejście do puli dla systemów Debian / Ubuntu. W przypadku RHEL wolę używać WWN urządzeń na ogólnych urządzeniach puli. Ale innym razem przydatna jest także nazwa / numer seryjny urządzenia. Ale udev powinien mieć to wszystko pod kontrolą.

# 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
ewwhite
źródło
1
Po migracji do nagich wwn-*nazw pula wydaje się być stabilna.
CVn
1
@ MichaelKjörling czy możesz szczegółowo opisać migrację do nazw wwn- *?
codecowboy
1
@codecowboy Nic szczególnego. zpool detach akita ST4000NM0033-Z1Z333ZANastępnie zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414apo czym zpool detach akita ST4000NM0033-Z1Z1A0LQnastępnie zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, sprawdzając pomiędzy każdym kroku, że basen był stabilny. Najpierw bardzo polecam dokładne szorowanie. Prawdopodobnie można również uciec, zpool replaceale ponieważ aliasy wskazywały na wwn nazwy, a ja miałem nadmiarowość i kopie zapasowe, czułem się bezpieczniej. Zajęło mi to kilka dni, ale nie spieszyłem się.
CVn