
최근에 대량 데이터 스토리지 풀(ZFS On 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 작업 설정이 있습니다. 그러나 새 HDD가 미러에서 떨어질 것이라고는 전혀 예상하지 못했습니다.
/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
리실버링 중입니다. 리실버 작업을 시작한 지 약 1시간 만에 180G를 스캔하고 24G를 9.77% 완료하여 리실버링했습니다. 이는 전체 리실버를 수행하지 않고 데이터 세트 델타만 전송한다는 것을 의미합니다.
솔직히 이 문제가 Linux의 ZFS 또는 udev와 관련이 있는지 확실하지 않습니다(udev와 비슷한 냄새가 나지만 왜 한 드라이브는 잘 감지되고 다른 드라이브는 감지되지 않습니까). 그러나 제 질문은 다음과 같습니다.다음에 재부팅할 때 같은 일이 다시 발생하지 않도록 하려면 어떻게 해야 합니까?
필요한 경우 설정에 대한 추가 데이터를 기꺼이 제공해 드리겠습니다. 필요한 것이 무엇인지 알려주세요.
답변1
이것은 udev 문제인 것 같습니다.Debian 및 Ubuntu 변형에만 해당. Linux에서 ZFS 작업의 대부분은 CentOS/RHEL을 사용합니다.
ZFS 토론 목록의 유사한 스레드에서 이에 대해 언급했습니다.
보다:
/dev/disk/by-id 아래의 동일한 하드 드라이브에 대한 scsi 및 ata 항목
그리고
Linux/Ubuntu의 ZFS: Ubuntu를 13.04에서 13.10으로 업그레이드한 후 zpool을 가져오는 데 도움이 되며 장치 ID가 변경되었습니다.
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