मेरे पास एक ज़ूल में बहुत मूल्यवान व्यक्तिगत डेटा के कई टीबी हैं जो मैं डेटा भ्रष्टाचार के कारण नहीं पा सकता हूं। पूल को मूल रूप से 2009 में स्थापित किया गया था या एक उबंटू 8.04 सिस्टम के शीर्ष पर एक VMWare वर्चुअल मशीन के अंदर चल रहे FreeBSD 7.2 सिस्टम पर। फ्रीबीएसडी वीएम अभी भी उपलब्ध है और ठीक चल रहा है, केवल होस्ट ओएस अब डेबियन 6. में बदल गया है। हार्ड ड्राइव को अतिथि वीएम द्वारा VMWare जेनेरिक SCSI उपकरणों के माध्यम से सुलभ बनाया गया है, कुल 12।
2 पूल हैं:
- zpool01: 2x 4x 500GB
- 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
मैं कुछ हफ़्ते पहले पूल का उपयोग करने में सक्षम था। तब से, मुझे होस्ट मशीन के सभी हार्डवेयर को बदलना पड़ा और कई होस्ट ऑपरेटिंग सिस्टम को स्थापित करना पड़ा।
मेरा संदेह यह है कि इन OS संस्थापनों में से एक ने 500GB ड्राइव में से एक (पहले) को बूटलोडर (या जो कुछ भी) लिखा था और कुछ ज़ूलर मेटाडेटा (या जो कुछ भी) को नष्ट कर दिया - 'या जो भी' का अर्थ है कि यह सिर्फ एक बहुत ही अस्पष्ट विचार है और यह विषय वास्तव में मेरा मजबूत पक्ष नहीं है ...
ZFS के बारे में बहुत सारी वेबसाइट, ब्लॉग, मेलिंग लिस्ट आदि है। मैं इस सवाल को यहां इस उम्मीद में पोस्ट करता हूं कि यह मेरे डेटा को वापस पाने के लिए एक समझदार, संरचित, नियंत्रित, सूचित, जानकार दृष्टिकोण के लिए पर्याप्त जानकारी इकट्ठा करने में मदद करता है - और उम्मीद है कि उसी स्थिति में किसी और की मदद करें।
पहला खोज परिणाम जब 'zfs पुनर्प्राप्त' के लिए googling, Solaris ZFS प्रशासन गाइड से ZFS समस्या निवारण और डेटा रिकवरी अध्याय है। पहले ZFS विफलता मोड अनुभाग में, यह 'भ्रष्ट ZFS डेटा' पैराग्राफ में कहता है:
डेटा भ्रष्टाचार हमेशा स्थायी होता है और मरम्मत के दौरान विशेष विचार की आवश्यकता होती है। यहां तक कि अगर अंतर्निहित उपकरणों की मरम्मत या प्रतिस्थापित किया जाता है, तो मूल डेटा हमेशा के लिए खो जाता है।
कुछ हद तक निराशाजनक।
हालांकि, दूसरा Google खोज परिणाम मैक्स ब्रूनिंग का वेबलॉग है और वहां, मैंने पढ़ा
हाल ही में, मुझे किसी ऐसे व्यक्ति से एक ईमेल भेजा गया था जिसके पास 15 साल का वीडियो और संगीत 10TB ZFS पूल में संग्रहीत था, जो कि बिजली की विफलता के बाद दोषपूर्ण हो गया। दुर्भाग्य से उनके पास बैकअप नहीं था। वह फ्रीबीएसडी 7 पर जेडएफएस संस्करण 6 का उपयोग कर रहा था [...] डिस्क पर डेटा की जांच करने में लगभग 1 सप्ताह बिताने के बाद, मैं मूल रूप से यह सब बहाल करने में सक्षम था।
तथा
आपके डेटा को खोने वाले ZFS के लिए, मुझे संदेह है। मुझे संदेह है कि आपका डेटा वहां मौजूद है, लेकिन आपको इसे प्राप्त करने का सही तरीका खोजने की आवश्यकता है।
(यह बहुत अधिक लगता है जैसे मैं सुनना चाहता हूँ ...)
पहला कदम : वास्तव में समस्या क्या है?
मैं यह कैसे निदान कर सकता हूं कि वास्तव में झूले को भ्रष्ट क्यों बताया गया है? मैं देखता हूं कि zdb है जो वेब पर कहीं भी आधिकारिक रूप से सन या ओरेकल द्वारा प्रलेखित नहीं लगता है। इसके मैन पेज से:
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.
इसके अलावा, बेन रॉकवुड ने एक विस्तृत लेख पोस्ट किया है और 28 जून, 2008 को प्राग में ओपन सोलारिस डेवलपर सम्मेलन में मैक्स ब्रूनिंग के बारे में बात करते हुए (और एमडीबी) का एक वीडियो है।
टूटी हुई ज़ूल पर रूट के रूप में रनिंग zdb निम्नलिखित आउटपुट देता है:
[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:
मुझे लगता है कि मुझे मूल कारण मिल गया है: मैक्स ब्रूनिंग काफी जल्दी से मेरा एक ईमेल का जवाब देने के लिए पर्याप्त था, आउटपुट के लिए पूछ रहा था zdb -lll। पूल के 'अच्छे' raidz1 आधा में 4 हार्ड ड्राइव में से किसी पर, आउटपुट मैं ऊपर पोस्ट के समान है। हालाँकि, 'टूटी हुई' आधी में 4 ड्राइव के पहले 3 पर, लेबल 2 और 3 के लिए zdbरिपोर्ट failed to unpack label। पूल में चौथा ड्राइव ठीक लगता है, zdbसभी लेबल दिखाता है।
Googling कि त्रुटि संदेश इस पोस्ट को लाता है । उस पोस्ट की पहली प्रतिक्रिया से:
ZFS के साथ, कि प्रत्येक भौतिक vdev पर 4 समान लेबल हैं, इस मामले में एक ही हार्ड ड्राइव है। VV की शुरुआत में L0 / L1, और V2 के अंत में L2 / L3।
पूल में सभी 8 ड्राइव एक ही मॉडल हैं, सीगेट बाराकुडा 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 एमबी से सिकुड़ गए हैं:
[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)
तो इसके लुक के अनुसार, यह ओएस इंस्टॉलेशन में से एक नहीं था कि 'एक ड्राइव के लिए एक बूटलोडर लिखा था' (जैसा कि मैंने पहले मान लिया था), यह वास्तव में नया मदरबोर्ड ( एएसयूएस P8P67 LE ) था जो 2 एमबी होस्ट बना रहा था मेरे ZFS मेटाडेटा को गड़बड़ करने वाले तीन ड्राइव के अंत में संरक्षित क्षेत्र ।
इसने सभी ड्राइव्स पर HPA क्यों नहीं बनाया? मेरा मानना है कि यह इसलिए है क्योंकि HPA निर्माण केवल पुराने ड्राइव पर बग के साथ किया जाता है जिसे बाद में Seagate हार्ड ड्राइव BIOS अद्यतन द्वारा तय किया गया था: जब यह पूरी घटना कुछ हफ़्ते पहले शुरू हुई थी, तो मैं जाँचने के लिए Seagate SeaTools चला। ड्राइव के साथ शारीरिक रूप से कुछ भी गलत (अभी भी पुराने हार्डवेयर पर) और मुझे एक संदेश मिला जिसमें बताया गया था कि मेरे कुछ ड्राइव में BIOS अपडेट की आवश्यकता है। जैसा कि मैं अब उस संदेश के सटीक विवरण और फ़र्मवेयर अपडेट डाउनलोड के लिंक को पुन: प्रस्तुत करने की कोशिश कर रहा हूं, ऐसा लगता है कि जब से मदरबोर्ड ने एचपीए को बनाया है, दोनों सीटोस डॉस संस्करणों को प्रश्न में हार्डड्राइव का पता लगाने में विफल होते हैं - एक त्वरित invalid partitionया कुछ इसी तरह का जब वे शुरू करते हैं, तब तक यह चमकता है। विडंबना यह है कि वे सैमसंग ड्राइव का एक सेट पाते हैं, हालांकि।
(मैंने एक गैर-नेटवर्क प्रणाली पर एक फ्रीडोस शेल में चारों ओर पंगा लेने के दर्दनाक, समय लेने वाली और अंततः फल रहित विवरणों पर छोड़ दिया है।) अंत में, मैंने सीटल्स विंडोज को चलाने के लिए एक अलग मशीन पर विंडोज 7 स्थापित किया। संस्करण 1.2.0.5। DOS SeaTools के बारे में बस एक अंतिम टिप्पणी: उन्हें स्टैंडअलोन बूट करने की कोशिश करने से परेशान न हों - इसके बजाय, कुछ मिनटों का निवेश करें और भयानक अल्टिमेट बूट सीडी के साथ एक बूट करने योग्य USB स्टिक बनाएं - जो कि DOS SeaTools के अलावा आपको कई सारे सच भी देता है उपयोगी उपकरण।
जब प्रारंभ किया गया, तो Windows के लिए SeaTools इस संवाद को लाते हैं:
लिंक सीरियल नंबर चेकर की ओर ले जाते हैं (जो किसी कारण से कैप्चा द्वारा संरक्षित होता है - मेरा 'इनवेसिव यूजर्स' था) और फर्मवेयर अपडेट के बारे में ज्ञान का आधार लेख । हार्ड ड्राइव मॉडल और कुछ डाउनलोड के लिए संभवतः विशिष्ट लिंक हैं और क्या नहीं, लेकिन मैं फिलहाल उस रास्ते का पालन नहीं करूंगा:
मैं एक बार में तीन ड्राइव के फर्मवेयर को अपडेट करने में जल्दबाजी नहीं करूंगा, जिसमें विभाजन अलग हो गए हैं और टूटे हुए स्टोरेज पूल का हिस्सा हैं। वह मुसीबत पूछ रहा है। शुरुआत के लिए, फर्मवेयर अपडेट सबसे अधिक संभावना से पूर्ववत नहीं हो सकता है - और यह मेरे डेटा को वापस पाने के लिए मेरे अवसरों को पूरी तरह से बर्बाद कर सकता है।
इसलिए, मैं जो सबसे पहली चीज करने जा रहा हूं वह है ड्राइव्स की इमेज और कॉपियों के साथ काम करना, इसलिए अगर आपको कुछ भी गलत लगे तो वापस जाने का ऑरिजनल है। यह एक अतिरिक्त जटिलता का परिचय दे सकता है, क्योंकि ZFS शायद नोटिस करेगा कि ड्राइव को स्वैप किया गया था (ड्राइव सीरियल नंबर के माध्यम से या फिर एक और UUID या जो भी हो), भले ही यह उसी हार्ड ड्राइव मॉडल पर बिट-सटीक dd प्रतियां हो। इसके अलावा, ज़ूल भी लाइव नहीं है। लड़का, यह मुश्किल हो सकता है।
हालांकि दूसरा विकल्प मूल के साथ काम करना और मिरर किए गए ड्राइव को बैकअप के रूप में रखना होगा, लेकिन तब मैं शायद जटिलता से ऊपर जाऊंगा जब कुछ मूल के साथ कुछ गलत हुआ। ना, अच्छा नहीं।
टूटे हुए पूल में बग्गी BIOS के साथ तीन ड्राइव के लिए imaged रिप्लेसमेंट के रूप में काम करने वाली तीन हार्ड ड्राइव को खाली करने के लिए, मुझे उस सामान के लिए कुछ स्टोरेज स्पेस बनाने की आवश्यकता है जो अभी वहां पर है, इसलिए मैं गहरी खुदाई करूँगा हार्डवेयर बॉक्स और कुछ पुराने ड्राइव से एक अस्थायी झूले को इकट्ठा करें - जो कि मैं यह परीक्षण करने के लिए भी उपयोग कर सकता हूं कि ZFS कैसे स्वैपिंग डीडीए ड्राइव के साथ काम करता है।
इसमें कुछ समय लग सकता है...
20111213-1930 + 1100
अद्यतन 02:
यह वास्तव में कुछ समय लगा। मैंने अपने डेस्क पर कई खुले कंप्यूटर मामलों के साथ कई महीने बिताए हैं जिसमें हार्डड्राइव स्टैक्स बाहर लटकाए गए हैं और इयरप्लग के साथ कुछ रातों को सोया है, क्योंकि मैं बिस्तर पर जाने से पहले मशीन को बंद नहीं कर सकता था क्योंकि यह कुछ लंबा महत्वपूर्ण ऑपरेशन चला रहा था। । हालाँकि, मैं पिछले पर प्रबल! :-) मैंने भी इस प्रक्रिया में बहुत कुछ सीखा है और मैं उस ज्ञान को एक समान स्थिति में किसी के लिए भी साझा करना चाहूंगा।
यह आलेख पहले से ही किसी से अधिक लंबा है ZFS फ़ाइल सर्वर के साथ कार्रवाई से बाहर पढ़ने का समय है, इसलिए मैं यहां विवरणों में जाऊंगा और नीचे आवश्यक निष्कर्षों के साथ उत्तर दूंगा।
मैं अप्रचलित हार्डवेयर बॉक्स में गहरी खोदता हूं ताकि 500 जीबी ड्राइव से सामान को स्थानांतरित करने के लिए पर्याप्त स्टोरेज स्पेस इकट्ठा हो सके जिसमें दोषपूर्ण ड्राइव मिरर किए गए थे। मुझे उनके यूएसबी मामलों में से कुछ हार्ड ड्राइव को चीरना पड़ा, इसलिए मैं उन्हें सीधे SATA से जोड़ सकता था। इसमें कुछ और, असंबंधित मुद्दे शामिल थे और कुछ पुराने ड्राइव विफल होने लगे, जब मैंने उन्हें वापस एक बदले की जगह की आवश्यकता के लिए कार्रवाई में डाल दिया, लेकिन मैं उस पर छोड़ दूंगा।
युक्ति: किसी स्तर पर, इसमें लगभग 30 हार्ड ड्राइव शामिल थे। उस बहुत हार्डवेयर के साथ, उन्हें ठीक से स्टैक्ड करने में बहुत मदद मिलती है; आपके डेस्क से गिरने वाली ढीली या हार्ड ड्राइव निश्चित रूप से प्रक्रिया में मदद नहीं करेगी और आपके डेटा अखंडता को और नुकसान पहुंचा सकती है।
मैंने कुछ मेक-शिफ्ट कार्डबोर्ड हार्ड ड्राइव जुड़नार बनाने में कुछ मिनट बिताए जो वास्तव में चीजों को क्रमबद्ध रखने में मदद करते हैं:
विडंबना यह है कि जब मैंने पहली बार पुरानी ड्राइव को कनेक्ट किया था, तो मुझे एहसास हुआ कि वहाँ एक पुरानी ज़ूलप है जो मैंने कुछ पुराने संस्करण के साथ परीक्षण के लिए बनाई होगी, लेकिन सभी व्यक्तिगत डेटा जो गायब हो गए हैं, इसलिए नहीं, जबकि डेटा हानि थी कुछ हद तक कम, इसका मतलब फाइलों के आगे-पीछे स्थानांतरण।
अंत में, मैंने समस्याग्रस्त ड्राइव को बैकअप ड्राइव पर प्रतिबिंबित किया, जो कि ज़ूल के लिए इस्तेमाल किया और मूल वाले को काट दिया। बैकअप ड्राइव में एक नया फर्मवेयर है, कम से कम SeaTools किसी भी आवश्यक फर्मवेयर अपडेट की रिपोर्ट नहीं करता है। मैंने एक डिवाइस से दूसरे डिवाइस पर एक साधारण dd के साथ मिररिंग किया, जैसे
sudo dd if=/dev/sda of=/dev/sde
मेरा मानना है कि ZFS हार्डवेयर परिवर्तन (कुछ हार्ड ड्राइव UUID या जो भी हो) द्वारा नोटिस करता है, लेकिन इसकी परवाह नहीं करता है।
हालाँकि, ज़ूलप अभी भी उसी स्थिति में था, अपर्याप्त प्रतिकृतियां / दूषित डेटा।
जैसा कि पहले उल्लेख किए गए HPA विकिपीडिया लेख में उल्लेख किया गया है, एक मेजबान संरक्षित क्षेत्र की उपस्थिति की रिपोर्ट तब की जाती है जब लिनक्स बूट और एचडीपीआर का उपयोग करके जांच की जा सकती है । जहाँ तक मुझे पता है, FreeBSD पर कोई hdparm टूल उपलब्ध नहीं है, लेकिन इस समय तक, मेरे पास वैसे भी FreeBSD 8.2 और डेबियन 6.0 दोहरे-बूट सिस्टम के रूप में स्थापित था, इसलिए मैंने लिनक्स में बूट किया:
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
...
तो समस्या स्पष्ट रूप से यह थी कि नए मदरबोर्ड ने ड्राइव के अंत में मेगाबाइट के एक जोड़े का एचपीए बनाया था जो ऊपरी दो जेडएफएस लेबल को छिपाता था, अर्थात जेडएफएस को देखने से रोकता था।
एचपीए के साथ डबिंग एक खतरनाक व्यवसाय लगता है। HDParm मैन पेज से, पैरामीटर -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.
...
मेरे मामले में, एचपीए को इस तरह हटा दिया जाता है:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
और एक HPA के साथ अन्य ड्राइव के लिए उसी तरह। यदि आपको गलत ड्राइव या आपके द्वारा निर्दिष्ट आकार पैरामीटर के बारे में कुछ पता नहीं है, तो एचडीपीआर आंकड़ा के लिए पर्याप्त स्मार्ट है:
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.
उसके बाद, मैंने फ्रीबीएसडी 7.2 वर्चुअल मशीन को फिर से शुरू किया, जिस पर मूल रूप से ज़ूलप बनाया गया था और ज़ूलू स्थिति ने एक कामकाजी पूल को फिर से रिपोर्ट किया था। वाह! :-)
मैंने वर्चुअल सिस्टम पर पूल का निर्यात किया और इसे होस्ट फ्रीबीएसडी 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 पूल बहुत, मारने के लिए बहुत कठिन हैं। सन के लोग, जिन्होंने उस सिस्टम को बनाया है, के पास सभी कारण हैं जो इसे फाइल सिस्टम में अंतिम शब्द कहते हैं। आदर करना!