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 trigger
spowodował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 ONLINE
spręż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.
wwn-*
nazw pula wydaje się być stabilna.zpool detach akita ST4000NM0033-Z1Z333ZA
Następniezpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414a
po czymzpool detach akita ST4000NM0033-Z1Z1A0LQ
następniezpool 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 replace
ale 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ę.