एक निष्क्रिय RAID डिवाइस को फिर से कैसे काम करना है?

Question

बूट करने के बाद, मेरा RAID1 डिवाइस ( /dev/md_d0*) कभी-कभी कुछ अजीब स्थिति में चला जाता है और मैं इसे माउंट नहीं कर सकता।

^{* मूल रूप से मैंने बनाया है, /dev/md0लेकिन यह किसी तरह खुद में बदल गया है /dev/md_d0।}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

RAID युक्ति किसी भी तरह निष्क्रिय प्रतीत होती है :

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

प्रश्न यह है कि डिवाइस को फिर से कैसे सक्रिय किया जाए (उपयोग करते हुए mdmadm, मुझे लगता है)?

(अन्य समय यह बूट के बाद ठीक है (सक्रिय), और मैं इसे मैन्युअल रूप से समस्याओं के बिना माउंट कर सकता हूं। लेकिन यह अभी भी स्वचालित रूप से माउंट नहीं होगा, जबकि मैं इसमें शामिल हूं /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

तो एक बोनस सवाल: मुझे क्या करना चाहिए कि RAID डिवाइस /optबूट समय पर स्वचालित रूप से माउंट हो जाए ? )

यह एक उबंटू 9.10 वर्कस्टेशन है। इस सवाल में मेरी RAID सेटअप के बारे में पृष्ठभूमि की जानकारी ।

संपादित करें : मेरा /etc/mdadm/mdadm.confऐसा दिखता है। मैंने इस फ़ाइल को कभी नहीं छुआ है, कम से कम हाथ से।

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

में /proc/partitionsअंतिम प्रविष्टि है md_d0अब, जब डिवाइस फिर से सक्रिय होने के लिए होता है कम से कम रिबूट के बाद। (मुझे यकीन नहीं है कि यह निष्क्रिय होने पर समान होगा।)

समाधान : जैसा कि जिमी हेडमैन ने सुझाव दिया , मैंने इसका आउटपुट लिया mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

और इसे इसमें जोड़ा /etc/mdadm/mdadm.conf, जिससे लगता है कि मुख्य समस्या तय हो गई है। फिर /etc/fstabसे उपयोग करने के लिए /dev/md0(बदले में /dev/md_d0) बदलने के बाद , RAID डिवाइस भी स्वचालित रूप से माउंट हो जाता है!

Answer 1

आपके बोनस प्रश्न के लिए:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Comments

ठीक है, mdadm --examine --scanउत्पादित ARRAY /dev/md0 level=raid1 num-devices=2 UUID=...(md_d0 के बजाय md0 पर ध्यान दें!) मैंने उसे mdadm.conf फ़ाइल में डाला (मैन्युअल रूप से, क्योंकि sudo और >>("अनुमति अस्वीकृत") के साथ कुछ समस्या थी , और sudo की आवश्यकता है) और अद्यतन करने के लिए fstab का भी उपयोग किया md0 (md_d0 नहीं) फिर से। अब मैं "निष्क्रिय" समस्या में नहीं चल रहा लगता है और RAID डिवाइस बूटिंग पर स्वतः / पर निर्भर करता है। तो धन्यवाद!

— जोनीक

आपके पास समस्याओं का कारण यह sudo ... >> mdadm.confहै कि शेल सूडो चलाने से पहले पुनर्निर्देशित फ़ाइलों को खोलता है। कमांड su -c '.... >> mdadm.conf'को काम करना चाहिए।

— मेई

Answer 2

मैंने पाया है कि /etc/mdadm/mdadm.confरिबूट पर लिनक्स माउंट करने के लिए मुझे मैन्युअल रूप से सरणी को जोड़ना होगा । नहीं तो मुझे ठीक वही मिलता है जो आपके यहाँ है - md_d1-देवता जो निष्क्रिय हैं आदि।

Conf-file को नीचे की ओर देखना चाहिए - यानी ARRAYप्रत्येक md-device के लिए एक-लाइन। मेरे मामले में इस फ़ाइल में नए सरणियाँ गायब थीं, लेकिन अगर आपने उन्हें सूचीबद्ध किया है तो संभवतः यह आपकी समस्या का समाधान नहीं है।

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

एक सरणी प्रति md-device जोड़ें, और उपरोक्त टिप्पणी के बाद उन्हें जोड़ें, या यदि कोई टिप्पणी मौजूद नहीं है, तो फ़ाइल के अंत में। आप कर के UUIDs प्राप्त करते हैं sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

जैसा कि आप देख सकते हैं कि आप स्कैन में परिणाम से कॉपी फ़ाइल में बहुत अधिक उत्पादन कर सकते हैं।

मैं ubuntu डेस्कटॉप 10.04 LTS चलाता हूं, और जहां तक ​​मुझे याद है कि यह व्यवहार उबंटू के सर्वर संस्करण से भिन्न है, हालांकि यह बहुत समय पहले मैंने सर्वर पर अपने md-devices बनाए थे जो मैं गलत हो सकता है। यह भी हो सकता है कि मुझे कुछ विकल्प याद न हो।

वैसे भी, conf-file में ऐरे को जोड़ने से ट्रिक लगती है। मैंने उपर्युक्त छापे 1 और छापे 5 वर्षों तक बिना किसी समस्या के चलाया है।

Comments

तो अनिवार्य रूप से आप वही बात कह रहे हैं जो वर्तमान में स्वीकृत उत्तर के रूप में है, बस अधिक मौखिक रूप से? :) फिर भी, +1, अच्छी पहली पोस्ट।

— जोनीक

Answer 3

चेतावनी: सबसे पहले मुझे यह बताने दें कि नीचे ("--फोर्स" के उपयोग के कारण) मुझे जोखिम भरा लगता है, और यदि आपके पास अपूरणीय डेटा है, तो मैं आपको किसी भी प्रयास की शुरुआत करने से पहले शामिल विभाजन की प्रतियां बनाने की सलाह दूंगा। नीचे दी गई बातें। हालांकि, इसने मेरे लिए काम किया।

मुझे एक ही समस्या थी, एक सरणी को निष्क्रिय दिखाने के साथ, और कुछ भी नहीं जिसमें मैंने "mdadm --examine --scan> /etc/mdadm.conf" शामिल किया था, जैसा कि यहां दूसरों द्वारा सुझाया गया है, सभी में मदद की।

मेरे मामले में, जब उसने ड्राइव रिप्लेसमेंट के बाद RAID-5 सरणी शुरू करने की कोशिश की, तो यह कह रहा था कि यह गंदा था (माध्यम से dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

इसके कारण इसे निष्क्रिय दिखाने के लिए /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

मैंने पाया कि उन सभी उपकरणों पर एक ही घटना थी, सिवाय उस ड्राइव के जिसे मैंने प्रतिस्थापित किया था ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

हालाँकि, सरणी विवरण से पता चला कि इसमें 5 में से 4 डिवाइस उपलब्ध थे:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(ऊपर "स्टेट" कॉलम पर मेमोरी से है, मैं इसे अपने स्क्रॉल-बैक बफर में नहीं पा सकता हूं)।

मैं इसे रोककर सरणी को हल करने में सक्षम था और फिर इसे फिर से इकट्ठा कर रहा था:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

उस बिंदु पर सरणी ऊपर थी, 5 में से 4 उपकरणों के साथ चल रही थी, और मैं प्रतिस्थापन डिवाइस को जोड़ने में सक्षम था और यह पुनर्निर्माण कर रहा है। मैं बिना किसी समस्या के फ़ाइल-सिस्टम तक पहुँचने में सक्षम हूँ।

Answer 4

मैं Ubuntu 10.04 के साथ समस्या कर रहा था जहां FStab में एक त्रुटि सर्वर को बूट करने से रोकती थी।

मैंने इस कमांड को उपरोक्त समाधानों में बताया है:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

यह "mdadm --examine --scan" से "/etc/mdadm/mdadm.conf" के परिणामों को जोड़ देगा।

मेरे मामले में, यह था:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

यह एक fakeraid 0. स्वचालित रूप से बढ़ते के लिए / etc / fstab में मेरा आदेश है:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

यहाँ महत्वपूर्ण बात यह है कि आपके पास "nobootwait" और "nofail" हैं। नोबूटवाइट किसी भी सिस्टम संदेश को छोड़ देगा जो आपको बूट करने से रोक रहा है। मेरे मामले में, यह एक दूरस्थ सर्वर पर था इसलिए यह आवश्यक था।

आशा है कि इससे कुछ लोगों को मदद मिलेगी।

Comments

मेरे लिए यही किया। मेरे पास मेरी RAID ड्राइव एक PCI एक्सप्रेस SATA कार्ड के माध्यम से जुड़ी हुई है, इसलिए मैं बूट समय पर अनुमान लगा रहा हूं कि सिस्टम अभी तक उन ड्राइव को नहीं देख सका है।

— माइकल रॉबिन्सन

Answer 5

आप अपने md डिवाइस को सक्रिय कर सकते हैं

mdadm -A /dev/md_d0

मुझे लगता है कि कुछ स्टार्टअप स्क्रिप्ट बहुत जल्द शुरू हो जाती है, इससे पहले कि एक आरओडी सदस्य की खोज की गई थी या कुछ इसी तरह की समस्या थी। एक त्वरित और गंदे वर्कअराउंड के रूप में, आपको इस लाइन को /etc/rc.local में जोड़ने में सक्षम होना चाहिए:

mdadm -A /dev/md_d0 && mount /dev/md_d0

संपादित करें: जाहिरा तौर पर आपके /etc/mdadm/mdadm.conf में अभी भी पुराना कॉन्फ़िगरेशन नाम है। इस फ़ाइल को संपादित करें और md0 की घटनाओं को md_d0 से बदलें।

Comments

ठीक है, उन अवसरों पर डिवाइस है रिबूट के बाद सक्रिय, बस mount /dev/md_d0में /etc/rc.localकाम करता है ठीक। mdadm -A /dev/md_d0दूसरी ओर दोनों मामलों में उस त्रुटि संदेश के साथ विफल रहता है (इसलिए मैं उस &&ऑपरेटर से पहले इसका उपयोग नहीं कर सका )। वैसे भी, समस्या का आधा हल लगता है तो उसके लिए +1।

— जोनिक

वास्तव में mdadm.conf में कोई कॉन्फ़िगरेशन नाम नहीं है, कम से कम सीधे (यह /proc/partitionsहालांकि संदर्भित करता है ); संपादित प्रश्न देखें। मैंने mdadm.conf को कभी नहीं छुआ है - वह कौन सा उपकरण है जो इसे ऑटोजेनरेट करता है?

— जोनिक

रिकॉर्ड के लिए, /etc/rc.localवर्कअराउंड को हटा दिया क्योंकि ऐसा लगता है कि मुझे सब कुछ ठीक से काम कर रहा है: superuser.com/questions/117824/… :)

— जोनीक

Answer 6

मैं एक समान समस्या थी ... मेरे सर्वर ने md2 को माउंट नहीं किया होगा क्योंकि मैंने डिवाइस के विभाजन अलग कर दिए हैं। इस धागे को पढ़ने पर मैंने पाया कि md2 RAID डिवाइस में एक नया UUID था और मशीन पुराने का उपयोग करने की कोशिश कर रही थी।

जैसा कि सुझाव दिया गया है ... से 'md2' आउटपुट का उपयोग करना

mdadm --examine --scan

मैंने संपादित किया /etc/mdadm/mdadm.confऔर पुरानी UUID लाइन को कमांड से ऊपर के आउटपुट से बदल दिया और मेरी समस्या दूर हो गई।

Answer 7

जब आप कुछ करने के लिए नाटक के साथ /dev/md[012346789}यह करने के लिए चला जाता है /dev/md{126,127...}। /dev/md0जारी रखा है /dev/md126या /dev/md127आप पर है:

umount /dev/md127 या umount /dev/md126।

यह आपको अपने सिस्टम को रोकने के बिना कमांड और कुछ एप्लिकेशन निष्पादित करने के लिए अस्थायी है।

Answer 8

md_d0 : inactive sda4[0](S)RAID1 सरणी के लिए गलत दिखता है। ऐसा लगता है कि सरणी में कोई सक्रिय डिवाइस नहीं है और एक स्पेयर डिवाइस ^{_{(एस द्वारा दर्शाया गया है), आप एक असफल डिवाइस के लिए वहां (एफ) देखेंगे और एक ओके / सक्रिय डिवाइस के लिए कुछ भी नहीं है}} - एक RAID1 सरणी के लिए जो isn अपमानित नहीं चल रहा है, कम से कम दो ओके / सक्रिय डिवाइस ^{_{(और एक डिग्रेड किए गए सरणी के लिए, कम से कम एक ओके / सक्रिय डिवाइस) होना चाहिए}} और आप बिना किसी असफल नहीं-स्पेयर डिवाइस के साथ एक RAID1 सरणी को सक्रिय नहीं कर सकते (पुर्जों के रूप में) जब तक वे सक्रिय नहीं हो जाते, तब तक डेटा की एक प्रति शामिल न करें)। यदि मैं उस /proc/mdstatआउटपुट को सही पढ़ रहा हूं , तो आप इसकी वर्तमान स्थिति में सरणी को सक्रिय नहीं कर पाएंगे।

क्या आपके पास मशीन में कोई भौतिक ड्राइव है जो स्पिन-अप करने में विफल रहा है? क्या ls /dev/sd*उन सभी ड्राइव और विभाजनों को सूचीबद्ध करता है जिन्हें आप आमतौर पर उस मशीन पर देखने की उम्मीद करते हैं?

Comments

लगता है कि मैं जिमी के जवाब में सलाह का पालन करने के बाद किसी भी स्थिति में निष्क्रिय स्थिति को पुन: उत्पन्न नहीं कर सकता (ऐसा लगता है कि वैसे भी कुछ रिबूट के बाद) ... जो अच्छा है :) किसी भी मामले में धन्यवाद!

— जोनीक

: मैं लिनक्स RAID मेलिंग सूची के लिए इस राज्य का सवाल लाया है, और इस प्रतिक्रिया मिली spinics.net/lists/raid/msg61352.html

— NH2

जैसा कि मैंने अभी यहां लिखा है , echo active > /sys/block/md0/md/array_stateमेरे लिए काम किया, मेरे RAID बनाने के रूप में RAID1 के रूप में लापता डिस्क के साथ फिर से RAID0 के बजाय केवल स्पेयर के साथ।

— nh2

Answer 9

सरणी चलाने के लिए एक सरल तरीका है यह मानते हुए कि कोई हार्डवेयर समस्या नहीं है और सरणी शुरू करने के लिए आपके पास पर्याप्त ड्राइव / विभाजन हैं:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

यह हो सकता है कि किसी भी कारण से सरणी ठीक हो, लेकिन कुछ ने इसे शुरू या निर्माण से रोका। मेरे मामले में ऐसा इसलिए था क्योंकि mdadm को नहीं पता था कि मूल सरणी नाम md127 था और सभी ड्राइव उस सरणी के लिए अनप्लग थे। जब मैं अपने आप को इकट्ठा करना था (शायद एक बग जहां mdadm सोचा था कि सरणी पहले से ही ऑफ़लाइन पुराने सरणी नाम के कारण सक्रिय था)।