Gần đây tôi đã di chuyển một nhóm lưu trữ dữ liệu số lượng lớn (ZFS On Linux 0.6.2, Debian Wheezy) từ cấu hình vdev một thiết bị sang cấu hình vdev hai chiều.
Cấu hình nhóm trước đó là:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Mọi thứ đều ổn sau khi bộ giải mã hoàn thành (Tôi đã khởi tạo một bộ lọc sau khi bộ phục hồi hoàn thành, chỉ để hệ thống vượt qua mọi thứ một lần nữa và đảm bảo tất cả đều tốt):
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
Tuy nhiên, sau khi khởi động lại, tôi nhận được một email thông báo cho tôi về thực tế rằng hồ bơi không ổn và bảnh bao. Tôi đã có một cái nhìn và đây là những gì tôi thấy:
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
Chà được dự kiến; có một thiết lập công việc định kỳ để bắt đầu quá trình xóa toàn bộ hệ thống khi khởi động lại. Tuy nhiên, tôi chắc chắn đã không mong đợi ổ cứng mới rơi ra khỏi gương.
Tôi xác định các bí danh ánh xạ tới tên / dev / đĩa / by-id / wwn- * và trong trường hợp cả hai đĩa này đã cho ZFS trị vì miễn phí để sử dụng toàn bộ đĩa, bao gồm cả xử lý phân vùng:
# 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
#
Đây là các dòng có liên quan từ /etc/zfs/vdev_id.conf (Bây giờ tôi nhận thấy rằng Z1Z333ZA sử dụng ký tự tab để phân tách trong khi dòng Z1Z1A0LQ chỉ sử dụng khoảng trắng, nhưng tôi thực sự không thấy làm thế nào có thể liên quan ở đây) :
alias ST4000NM0033-Z1Z1A0LQ /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA /dev/disk/by-id/wwn-0x5000c50065e8414a
Khi tôi nhìn, /dev/disk/by-id/wwn-0x5000c50065e8414a*có như mong đợi, nhưng /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*không.
Việc phát hành sudo udevadm triggerkhiến các liên kết tượng trưng xuất hiện trong / dev / đĩa / by-vdev. Tuy nhiên, ZFS dường như không nhận ra rằng họ đang ở đó (Z1Z333ZA vẫn hiển thị như UNAVAIL). Điều đó tôi cho rằng có thể được mong đợi.
Tôi đã thử thay thế thiết bị có liên quan, nhưng không có may mắn thực sự:
# 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'
#
Cả hai đĩa được phát hiện trong quá trình khởi động (đầu ra nhật ký dmesg hiển thị các ổ đĩa có liên quan):
[ 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
Cả hai ổ đĩa được kết nối trực tiếp với bo mạch chủ; không có bộ điều khiển off-board liên quan.
Trước sự thúc đẩy, tôi đã làm:
# zpool online akita ST4000NM0033-Z1Z333ZA
có vẻ như đã làm việc; Z1Z333ZA hiện ít nhất ONLINEvà có khả năng phục hồi. Vào khoảng một giờ sau khi phục hồi, nó đã quét 180G và khôi phục 24G với 9,77% được thực hiện, điều này chỉ ra rằng nó không thực hiện một trình phục hồi hoàn toàn mà chỉ chuyển dữ liệu delta.
Tôi thực sự không chắc vấn đề này có liên quan đến ZFS trên Linux hay với udev (nó có mùi hơi giống udev, nhưng tại sao một ổ đĩa lại được phát hiện tốt mà không phải là ổ khác), nhưng câu hỏi của tôi là làm thế nào để tôi thực hiện chắc chắn điều tương tự không xảy ra lần nữa trong lần khởi động lại tiếp theo?
Tôi sẽ vui lòng cung cấp thêm dữ liệu về thiết lập nếu cần thiết; chỉ cho tôi biết những gì cần thiết.
wwn-*tên trần , hồ bơi có vẻ ổn định.