ฉันมีข้อมูลส่วนบุคคลที่มีค่ามากหลาย TBs ในสวนสัตว์ซึ่งฉันไม่สามารถเข้าถึงได้เนื่องจากข้อมูลเสียหาย เดิมพูลนั้นถูกตั้งค่าไว้ในปี 2009 หรือในระบบ FreeBSD 7.2 ที่ทำงานภายในเครื่องเสมือน VMWare ที่ด้านบนของระบบ Ubuntu 8.04 FreeBSD VM ยังคงมีอยู่และทำงานได้ดีมีเพียง OS โฮสต์ที่ได้รับการเปลี่ยนเป็น Debian 6 ฮาร์ดไดรฟ์นั้นสามารถเข้าถึงได้โดย VM guest โดยอุปกรณ์ VMWare SCSI ทั่วไปรวม 12 รายการ
มี 2 สระว่ายน้ำ:
- zpool01: 2x 4x500GB
- zpool02: 1x 4x 160GB
อันที่ทำงานว่างเปล่าอันที่พังนั้นเก็บข้อมูลสำคัญทั้งหมดไว้:
[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
Fri May 1 07:18:07 UTC 2009 \
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6
[user@host ~]$ sudo zpool status
pool: zpool01
state: UNAVAIL
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool01 UNAVAIL 0 0 0 insufficient replicas
raidz1 UNAVAIL 0 0 0 corrupted data
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
da8 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
pool: zpool02
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool02 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da9 ONLINE 0 0 0
da10 ONLINE 0 0 0
da11 ONLINE 0 0 0
da12 ONLINE 0 0 0
errors: No known data errors
ฉันสามารถเข้าใช้สระได้สองสามสัปดาห์ที่ผ่านมา ตั้งแต่นั้นมาฉันต้องเปลี่ยนฮาร์ดแวร์ทั้งหมดของเครื่องโฮสต์และติดตั้งระบบปฏิบัติการโฮสต์หลายตัว
ความสงสัยของฉันคือว่าหนึ่งในการติดตั้งระบบปฏิบัติการเหล่านี้ได้เขียน bootloader (หรืออะไรก็ตาม) ลงในไดรฟ์ 500GB หนึ่งตัว (หรือไม่?) และทำลาย metadata ของ zpool (หรืออะไรก็ตาม) - 'หรืออะไรก็ตาม' ซึ่งหมายความว่า และหัวเรื่องนั้นไม่ใช่ด้านที่แข็งแกร่งของฉัน ...
มีเว็บไซต์บล็อกรายการส่งเมลและอื่น ๆ อีกมากมายเกี่ยวกับ ZFS ฉันโพสต์คำถามนี้ที่นี่ด้วยความหวังว่ามันจะช่วยให้ฉันรวบรวมข้อมูลเพียงพอสำหรับวิธีการที่มีสติมีโครงสร้างมีการควบคุมแจ้งให้ความรู้เพื่อรับข้อมูลของฉันกลับมา - และหวังว่าจะช่วยคนอื่นในสถานการณ์เดียวกัน
ผลลัพธ์การค้นหาแรกเมื่อ googling สำหรับ 'zfs recovery' คือบทการแก้ไขปัญหา ZFS และการกู้คืนข้อมูลจากคู่มือการดูแลระบบ Solaris ZFS ในส่วนZFS Failure Modesมันกล่าวไว้ในวรรค 'Data ZFS ที่เสียหาย':
ความเสียหายของข้อมูลเป็นสิ่งที่ถาวรและต้องพิจารณาเป็นพิเศษในระหว่างการซ่อมแซม แม้ว่าอุปกรณ์พื้นฐานจะได้รับการซ่อมแซมหรือเปลี่ยนใหม่ข้อมูลต้นฉบับจะสูญหายไปตลอดกาล
ค่อนข้างน่าผิดหวัง
อย่างไรก็ตามผลการค้นหา google ครั้งที่สองคือเว็บล็อกของ Max Bruningและในนั้นฉันอ่าน
เมื่อเร็ว ๆ นี้ฉันได้รับอีเมลจากบุคคลที่มีวิดีโอและเพลง 15 ปีเก็บไว้ในสระ ZFS ขนาด 10TB ซึ่งหลังจากไฟฟ้าดับ น่าเสียดายที่เขาไม่มีข้อมูลสำรอง เขาใช้ ZFS เวอร์ชัน 6 บน FreeBSD 7 [... ] หลังจากใช้เวลาประมาณ 1 สัปดาห์ในการตรวจสอบข้อมูลบนดิสก์ฉันสามารถกู้คืนได้ทั้งหมด
และ
สำหรับ ZFS สูญเสียข้อมูลของคุณฉันสงสัยมัน ฉันสงสัยว่ามีข้อมูลของคุณอยู่ที่นั่น แต่คุณต้องหาวิธีที่เหมาะสมในการเข้าถึง
(นั่นฟังดูคล้ายกับสิ่งที่ฉันอยากได้ยิน ... )
ขั้นแรก : ปัญหาคืออะไรกันแน่?
ฉันจะวินิจฉัยได้อย่างไรว่าทำไม zpool ถึงรายงานว่าเสียหาย? ฉันเห็นว่ามี zdb ซึ่งดูเหมือนจะไม่ได้รับการบันทึกอย่างเป็นทางการโดย Sun หรือ Oracle ที่ใดก็ได้บนเว็บ จากหน้าคนของมัน:
NAME
zdb - ZFS debugger
SYNOPSIS
zdb pool
DESCRIPTION
The zdb command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is always consistent on
disk and is self-repairing, zdb should only be run under the direction
by a support engineer.
If no arguments are specified, zdb, performs basic consistency checks
on the pool and associated datasets, and report any problems detected.
Any options supported by this command are internal to Sun and subject
to change at any time.
นอกจากนี้ Ben Rockwood ได้โพสต์บทความโดยละเอียดและมีวิดีโอของ Max Bruning ที่พูดถึงเรื่องนี้ (และ mdb) ในการประชุมนักพัฒนา Open Solaris ในกรุงปรากเมื่อวันที่ 28 มิถุนายน 2551
การรัน zdb ในฐานะรูทบน zpool ที่เสียหายจะให้เอาต์พุตต่อไปนี้:
[user@host ~]$ sudo zdb zpool01
version=6
name='zpool01'
state=0
txg=83216
pool_guid=16471197341102820829
hostid=3885370542
hostname='host.domain'
vdev_tree
type='root'
id=0
guid=16471197341102820829
children[0]
type='raidz'
id=0
guid=48739167677596410
nparity=1
metaslab_array=14
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=4795262086800816238
path='/dev/da5'
whole_disk=0
DTL=202
children[1]
type='disk'
id=1
guid=16218262712375173260
path='/dev/da6'
whole_disk=0
DTL=201
children[2]
type='disk'
id=2
guid=15597847700365748450
path='/dev/da7'
whole_disk=0
DTL=200
children[3]
type='disk'
id=3
guid=9839399967725049819
path='/dev/da8'
whole_disk=0
DTL=199
children[1]
type='raidz'
id=1
guid=8910308849729789724
nparity=1
metaslab_array=119
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=5438331695267373463
path='/dev/da1'
whole_disk=0
DTL=198
children[1]
type='disk'
id=1
guid=2722163893739409369
path='/dev/da2'
whole_disk=0
DTL=197
children[2]
type='disk'
id=2
guid=11729319950433483953
path='/dev/da3'
whole_disk=0
DTL=196
children[3]
type='disk'
id=3
guid=7885201945644860203
path='/dev/da4'
whole_disk=0
DTL=195
zdb: can't open zpool01: Invalid argument
ฉันคิดว่าข้อผิดพลาด 'อาร์กิวเมนต์ไม่ถูกต้อง' ในตอนท้ายเกิดขึ้นเนื่องจาก zpool01 ไม่มีอยู่จริง: มันไม่ได้เกิดขึ้นกับ zpool02 ที่ใช้งานได้ แต่ดูเหมือนจะไม่มีผลลัพธ์ใด ๆ เพิ่มเติม ...
ตกลงในขั้นตอนนี้อาจเป็นการดีกว่าที่จะโพสต์สิ่งนี้ก่อนที่บทความจะยาวเกินไป
บางทีใครบางคนสามารถให้คำแนะนำกับฉันเกี่ยวกับวิธีการก้าวไปข้างหน้าจากที่นี่และในขณะที่ฉันรอการตอบสนองฉันจะดูวิดีโออ่านรายละเอียดของผลลัพธ์ zdb ด้านบนอ่านบทความ Bens และพยายามหาว่ามีอะไรบ้าง อะไร...
20110806-1600 + 1000
อัปเดต 01:
ฉันคิดว่าฉันได้พบสาเหตุ: แม็กซ์ Bruning zdb -lllก็ใจดีพอที่จะตอบอีเมลของเหมืองอย่างรวดเร็วขอให้การส่งออกของ ในฮาร์ดไดรฟ์ทั้ง 4 ตัวในส่วน 'ดี' raidz1 ของพูลผลลัพธ์จะคล้ายกับที่ฉันโพสต์ไว้ด้านบน อย่างไรก็ตามใน 3 ไดรฟ์แรกของ 4 ไดรฟ์ในครึ่ง 'แตก' zdbรายงานfailed to unpack labelสำหรับเลเบล 2 และ 3 ไดรฟ์ที่สี่ในพูลดูเหมือนว่า OK zdbแสดงเลเบลทั้งหมด
Googling ข้อผิดพลาดที่นำขึ้นโพสต์นี้ จากการตอบกลับแรกไปยังโพสต์นั้น:
ด้วย ZFS ที่มี 4 ป้ายชื่อเหมือนกันในแต่ละฟิสิคัล vdev ในกรณีนี้ฮาร์ดไดรฟ์เดียว L0 / L1 ที่จุดเริ่มต้นของ vdev และ L2 / L3 ที่ส่วนท้ายของ vdev
ทั้งหมด 8 ไดรฟ์ในสระว่ายน้ำที่มีรูปแบบเดียวกัน, Seagate Barracuda 500GB อย่างไรก็ตามฉันจำได้ว่าฉันเริ่มพูลด้วยไดรฟ์ 4 ตัวจากนั้นหนึ่งในนั้นก็ตาย หลังจากนั้นฉันเพิ่มอีก 4 ไดรฟ์ ด้วยเหตุผลดังกล่าวตัวระบุไดรฟ์และเฟิร์มแวร์จึงแตกต่างกัน:
[user@host ~]$ dmesg | egrep '^da.*?: <'
da0: <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device
da1: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da2: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da3: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da4: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da5: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da6: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da7: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da8: <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device
da9: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
ฉันจำได้ว่าไดรฟ์ทั้งหมดมีขนาดเท่ากัน เมื่อดูที่ไดรฟ์ในตอนนี้มันแสดงให้เห็นว่าขนาดมีการเปลี่ยนแปลงสำหรับสามตัวพวกเขามีขนาดเล็กลง 2 MB:
[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
ดังนั้นจากรูปลักษณ์ของมันมันไม่ใช่หนึ่งในการติดตั้งระบบปฏิบัติการที่ 'เขียน bootloader ไปยังไดรฟ์หนึ่ง' (ตามที่ฉันเคยคิดมาก่อน) มันเป็นเมนบอร์ดตัวใหม่ ( อัสซุส P8P67 LE ) สร้างโฮสต์ 2 MB พื้นที่คุ้มครองในตอนท้ายของไดรฟ์สามตัวซึ่งทำให้เมตาดาต้า ZFS ของฉันสับสน
ทำไมมันไม่สร้าง HPA ในทุกไดรฟ์ ผมเชื่อว่านี่เป็นเพราะการสร้าง HPA จะทำเฉพาะในไดรฟ์สูงอายุที่มีข้อผิดพลาดที่ได้รับการแก้ไขในภายหลังด้วยการปรับปรุงที่ซีเกทฮาร์ดไดรฟ์ BIOS: เมื่อเหตุการณ์ที่เกิดขึ้นทั้งหมดเริ่มสองสามสัปดาห์ที่ผ่านมาผมวิ่งของซีเกทSeaToolsเพื่อตรวจสอบว่ามี มีสิ่งผิดปกติทางร่างกายกับไดรฟ์ (ยังคงอยู่บนฮาร์ดแวร์เก่า) และฉันได้รับข้อความแจ้งให้ฉันทราบว่าไดรฟ์บางตัวของฉันต้องมีการอัพเดตไบออส ขณะที่ผมกำลังพยายามที่จะทำซ้ำรายละเอียดที่แน่นอนของข้อความที่และการเชื่อมโยงกับการดาวน์โหลดอัปเดตเฟิร์มมันก็ดูเหมือนว่าตั้งแต่เมนบอร์ดสร้าง HPA ทั้งรุ่น SeaTools DOS ที่จะล้มเหลวในการตรวจสอบ harddrives ในคำถาม - รวดเร็วinvalid partitionหรือสิ่งที่คล้ายกัน กะพริบเมื่อพวกเขาเริ่มต้นนั่นแหล่ะ น่าแปลกที่พวกเขาพบชุดไดรฟ์ของ Samsung
(ฉันข้ามรายละเอียดที่เจ็บปวดใช้เวลานานและไม่มีรายละเอียดในการไขสกรูในเชลล์ FreeDOS บนระบบที่ไม่ใช่เครือข่าย) ในท้ายที่สุดฉันติดตั้ง Windows 7 บนเครื่องแยกต่างหากเพื่อใช้งาน SeaTools Windows รุ่น 1.2.0.5 เป็นเพียงคำพูดสุดท้ายเกี่ยวกับ DOS SeaTools: อย่ากังวลกับการบูตพวกเขาแบบสแตนด์อโลน - แทนที่จะลงทุนสักสองสามนาทีแล้วทำ USB stick ที่สามารถบู๊ตได้พร้อมกับUltimate Boot CD ที่น่ากลัวซึ่งนอกเหนือจาก DOS SeaTools แล้ว เครื่องมือที่มีประโยชน์
เมื่อเริ่มต้น SeaTools สำหรับ Windows จะแสดงกล่องโต้ตอบนี้ขึ้น:
ลิงก์ที่นำไปสู่ตัวตรวจสอบหมายเลขซีเรียล (ซึ่งด้วยเหตุผลบางอย่างได้รับการคุ้มครองโดย captcha - mine คือ 'ผู้ใช้ที่บุกรุกได้') และบทความฐานความรู้เกี่ยวกับการอัปเดตเฟิร์มแวร์ อาจมีการเชื่อมโยงเพิ่มเติมเฉพาะกับรุ่นฮาร์ดไดรฟ์และการดาวน์โหลดบางอย่างและสิ่งที่ไม่ แต่ฉันจะไม่ทำตามเส้นทางนั้นสักครู่:
ฉันจะไม่รีบไปอัปเดตเฟิร์มแวร์ของสามไดรฟ์ในเวลาที่มีการตัดพาร์ติชันและเป็นส่วนหนึ่งของพูลหน่วยเก็บข้อมูลที่เสียหาย นั่นคือการขอปัญหา สำหรับผู้เริ่มต้นการอัพเดตเฟิร์มแวร์ส่วนใหญ่ไม่สามารถยกเลิกได้ - และนั่นอาจทำลายโอกาสของฉันในการกู้คืนข้อมูลของฉันโดยไม่ได้
ดังนั้นสิ่งแรกที่ฉันจะทำต่อไปคืออิมเมจไดรฟ์และทำงานกับสำเนาดังนั้นจึงมีต้นฉบับที่จะกลับไปหากมีอะไรผิดพลาด สิ่งนี้อาจนำเสนอความซับซ้อนเพิ่มเติมเนื่องจาก ZFS อาจสังเกตเห็นว่าไดรฟ์ถูกเปลี่ยน (โดยใช้หมายเลขซีเรียลของไดรฟ์หรือ UUID อื่นหรืออะไรก็ตาม) แม้ว่ามันจะเป็นสำเนา dd บิตแน่นอนบนฮาร์ดไดรฟ์รุ่นเดียวกันก็ตาม ยิ่งไปกว่านั้นสวนสัตว์ไม่ได้มีชีวิต เจ้านี่อาจจะยุ่งยาก
ตัวเลือกอื่น ๆ จะทำงานกับต้นฉบับและเก็บไดรฟ์ที่ทำมิเรอร์ไว้เป็นข้อมูลสำรอง แต่จากนั้นฉันอาจพบความซับซ้อนสูงกว่าเมื่อบางสิ่งผิดปกติกับต้นฉบับ นาไม่ดี
เพื่อล้างฮาร์ดไดรฟ์สามตัวที่จะทำหน้าที่แทนการถ่ายภาพสำหรับไดรฟ์ทั้งสามที่มี BIOS buggy ในพูลที่เสียฉันต้องสร้างพื้นที่เก็บข้อมูลสำหรับสิ่งที่อยู่ในนั้นดังนั้นฉันจะขุดลึกลงไป กล่องฮาร์ดแวร์และประกอบ zpool ชั่วคราวจากไดรฟ์เก่าบางตัวซึ่งฉันสามารถใช้เพื่อทดสอบว่า ZFS จัดการกับไดรฟ์ dd'd ได้อย่างไร
อาจใช้เวลาสักครู่ ...
20111213-1930 + 1100
อัปเดต 02:
สิ่งนี้ใช้เวลาสักครู่แน่นอน ฉันใช้เวลาหลายเดือนกับเคสคอมพิวเตอร์ที่เปิดอยู่หลายตัวบนโต๊ะพร้อมแฮ็คฮาร์ดไดรฟ์จำนวนมากแขวนอยู่กับที่และนอนหลับสองสามคืนด้วยที่อุดหูเพราะฉันไม่สามารถปิดเครื่องก่อนนอนเพราะมันทำงานที่สำคัญมาก . อย่างไรก็ตามฉันชนะในที่สุด! :-) ฉันได้เรียนรู้มากมายในกระบวนการและฉันต้องการแบ่งปันความรู้นั้นกับทุกคนในสถานการณ์ที่คล้ายกันนี้
บทความนี้มีความยาวกว่าใครก็ตามที่มีไฟล์เซิร์ฟเวอร์ ZFS ไม่ทำงานมีเวลาให้อ่านดังนั้นฉันจะเข้าไปดูรายละเอียดที่นี่และสร้างคำตอบด้วยการค้นพบที่สำคัญเพิ่มเติมด้านล่าง
ฉันขุดลึกลงไปในกล่องฮาร์ดแวร์ที่ล้าสมัยเพื่อรวบรวมพื้นที่เก็บข้อมูลเพียงพอที่จะย้ายสิ่งต่าง ๆ ออกจากไดรฟ์ 500GB เดียวซึ่งมีการทำสำเนาไดรฟ์ที่มีข้อบกพร่อง ฉันต้องดึงฮาร์ดไดรฟ์สองสามตัวออกจากเคส USB ของพวกเขาด้วยดังนั้นฉันจึงสามารถเชื่อมต่อพวกเขาผ่าน SATA ได้โดยตรง มีบางประเด็นที่ไม่เกี่ยวข้องที่เกี่ยวข้องและไดรฟ์เก่าบางตัวเริ่มต้นล้มเหลวเมื่อฉันนำพวกเขากลับไปสู่การปฏิบัติที่ต้องมีการเปลี่ยน zpool แต่ฉันจะข้ามมันไป
คำแนะนำ:ในบางขั้นตอนมีฮาร์ดไดรฟ์ทั้งหมดประมาณ 30 รายการที่เกี่ยวข้อง ด้วยฮาร์ดแวร์จำนวนมากมันเป็นความช่วยเหลืออย่างมากในการจัดวางอย่างถูกต้อง สายเคเบิลที่หลวมหรือฮาร์ดไดรฟ์ตกลงมาจากโต๊ะของคุณจะไม่ช่วยในกระบวนการนี้และอาจทำให้เกิดความเสียหายต่อความสมบูรณ์ของข้อมูล
ฉันใช้เวลาสองสามนาทีในการสร้างอุปกรณ์ติดตั้งฮาร์ดไดรฟ์แบบปรับเปลี่ยนได้ซึ่งช่วยให้เรียงลำดับสิ่งต่าง ๆ ได้ดี:
กระแทกแดกดันเมื่อฉันเชื่อมต่อไดรฟ์เก่าเป็นครั้งแรกฉันรู้ว่ามี zpool เก่าอยู่ที่นั่นฉันต้องสร้างสำหรับการทดสอบกับรุ่นเก่ากว่าบางส่วน แต่ไม่ใช่ข้อมูลส่วนบุคคลทั้งหมดที่หายไปดังนั้นในขณะที่ข้อมูลสูญหาย ลดลงบ้างนั่นหมายถึงการขยับไปมาของไฟล์เพิ่มเติม
ในที่สุดฉันได้ทำมิรเรอร์ไดรฟ์ที่มีปัญหาไปยังไดรฟ์สำรองใช้ไดรฟ์เหล่านั้นสำหรับ zpool และปล่อยให้หลุดการเชื่อมต่อเดิม ไดรฟ์สำรองมีเฟิร์มแวร์ที่ใหม่กว่าอย่างน้อย SeaTools ไม่รายงานการอัพเดตเฟิร์มแวร์ที่จำเป็น ฉันทำมิรเรอร์ด้วย dd แบบง่ายจากอุปกรณ์หนึ่งไปยังอีกเครื่องหนึ่งเช่น
sudo dd if=/dev/sda of=/dev/sde
ฉันเชื่อว่า ZFS สังเกตเห็นการเปลี่ยนแปลงฮาร์ดแวร์ (โดย UUID ของฮาร์ดไดรฟ์หรืออะไรก็ตาม) แต่ดูเหมือนจะไม่สนใจ
อย่างไรก็ตาม zpool ยังคงอยู่ในสถานะเดียวกันข้อมูลเรพลิกา / เสียหายไม่เพียงพอ
เป็นที่กล่าวถึงในบทความวิกิพีเดีย HPAกล่าวก่อนหน้านี้การปรากฏตัวของโฮสต์พื้นที่คุ้มครองมีรายงานเมื่อบูทลินุกซ์และสามารถตรวจสอบการใช้hdparm เท่าที่ฉันรู้ไม่มีเครื่องมือ hdparm ใน FreeBSD แต่ตอนนี้ฉันยังติดตั้ง FreeBSD 8.2 และ Debian 6.0 เป็นระบบดูอัลบูตดังนั้นฉันบูตเข้า Linux:
user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done
...
/dev/sdd:
max sectors = 976773168/976773168, HPA is disabled
/dev/sde:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdf:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdg:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdh:
max sectors = 976773168/976773168, HPA is disabled
...
ดังนั้นปัญหาที่เห็นได้ชัดคือเมนบอร์ดใหม่สร้าง HPA สองสามเมกะไบต์ที่ส่วนท้ายของไดรฟ์ซึ่ง 'ซ่อน' ป้ายกำกับ ZFS สองรายการด้านบนไว้นั่นคือป้องกันไม่ให้ ZFS เห็นพวกเขา
การเล่นน้ำกับ HPA ดูเหมือนจะเป็นธุรกิจที่อันตราย จากหน้า hdparm man พารามิเตอร์ -N:
Get/set max visible number of sectors, also known as the Host Protected Area setting.
...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles. By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
...
ในกรณีของฉัน HPA จะถูกลบออกเช่นนี้
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
และในทำนองเดียวกันสำหรับไดรฟ์อื่นที่มี HPA หากคุณได้รับไดรฟ์ที่ไม่ถูกต้องหรือบางอย่างเกี่ยวกับพารามิเตอร์ขนาดที่คุณระบุไม่น่าเชื่อถือ hdparm จะฉลาดพอที่จะคิด:
user@host:~$ sudo hdparm -Np976773168 /dev/sdx
/dev/sdx:
setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.
หลังจากนั้นฉันรีสตาร์ทเครื่องเสมือน FreeBSD 7.2 ที่ zpool สร้างขึ้นมา แต่เดิมและสถานะ zpool รายงานพูลการทำงานอีกครั้ง เย้! :-)
ฉันส่งออกพูลบนระบบเสมือนและนำเข้าอีกครั้งบนระบบ FreeBSD 8.2 โฮสต์
การอัพเกรดฮาร์ดแวร์ที่สำคัญบางอย่างการแลกเปลี่ยนเมนบอร์ดอื่นการอัปเดตพูล ZFS เป็น ZFS 4/15 การขัดถูอย่างละเอียดและตอนนี้สวนสัตว์ของฉันประกอบด้วย 8x1TB บวก 8x500GB ส่วน raidz2:
[user@host ~]$ sudo zpool status
pool: zpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool ONLINE 0 0 0
raidz2 ONLINE 0 0 0
ad0 ONLINE 0 0 0
ad1 ONLINE 0 0 0
ad2 ONLINE 0 0 0
ad3 ONLINE 0 0 0
ad8 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad14 ONLINE 0 0 0
ad16 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
errors: No known data errors
[user@host ~]$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/label/root 29G 13G 14G 49% /
devfs 1.0K 1.0K 0B 100% /dev
zpool 8.0T 3.6T 4.5T 44% /mnt/zpool
ในฐานะที่เป็นคำพูดสุดท้ายสำหรับฉันดูเหมือนว่ากลุ่ม ZFS นั้นยากมากที่จะฆ่า ผู้ชายจาก Sun ที่สร้างระบบนั้นมีเหตุผลทั้งหมดที่เรียกมันว่าคำสุดท้ายในระบบไฟล์ เคารพ!