Ubuntu ရှိ mdadm Array တွင် မအောင်မြင်သော Drive ကို အစားထိုးခြင်း။

ဤပို့စ်ပါ အချက်အလက်သည် Ubuntu 18.04 ကို အခြေခံထားပြီး ၎င်း၏ သိုလှောင်နေရာများတွင် ထည့်သွင်းထားသော mdadm ဗားရှင်းကို အခြေခံထားသည်။ v4.1-rc1 ရေးနေစဉ်။ ၎င်းသည် အခြားဗားရှင်းများအတွက် တရားဝင်နိုင်သည် သို့မဟုတ် မမှန်နိုင်ပါ။

မကြာသေးမီက ကျွန်ုပ်သည် mdadm RAID-6 ခင်းကျင်းတွင် ဒရိုက်ကိုးခုပါ ၀ င်သည့်ကျွန်ုပ်၏အိမ်တွင်းဖိုင်ဆာဗာတွင်ရုတ်တရက်ဒရိုက်ဗ်ချို့ယွင်းမှုဖြစ်ခဲ့သည်။ အမြဲတမ်း ကြောက်စရာကောင်းပါတယ်၊ ဒါပေမယ့် ကံကောင်းထောက်မစွာနဲ့ နောက်ရက်မှာ ပေးပို့ပြီးသား အစားထိုး drive ကို အမြန်ရှာနိုင်ခဲ့တဲ့အတွက် ပြန်လည်တည်ဆောက်မှုကို စတင်နိုင်ခဲ့ပါတယ်။

ဖိုင်ဆာဗာကို မူလက စတင်သတ်မှတ်သောအခါတွင် ကျွန်ုပ်သည် အနည်းငယ်စျေးသက်သာကြောင်း ဝန်ခံပါသည်။ drive နှစ်ခုသာ အမှန်တကယ် NAS drives (Seagate IronWolf) ဖြစ်ပြီး ကျန်သည် desktop drive (Seagate Barracuda) ဖြစ်သည်။ အံ့သြစရာမဟုတ်ပါ၊ ၎င်းသည် (သုံးနှစ်နီးပါးဝန်ဆောင်မှုပြီးနောက်) စွန့်လွှတ်ခဲ့သော desktop drive များထဲမှတစ်ခုဖြစ်သည်။ လုံးဝသေသွားပြီ။ ၎င်းကို desktop USB အပေါက်တစ်ခုသို့ ရွှေ့ပြီးနောက် ၎င်းမှထွက်လာသော အရာအားလုံးသည် တုန်လှုပ်ချောက်ချားဖွယ်ရာ နှိပ်သည့်အသံတစ်ခုဖြစ်ပြီး Ubuntu 20.04 နှင့် Windows 10 တို့က ၎င်းကို သိရှိနိုင်ခြင်းမရှိပေ။

အိုကေ၊ အစားထိုးခြင်းအပိုင်းသို့ရောက်သည် (ဟုတ်ပါတယ်၊ ကျွန်တော်ဝယ်ခဲ့တဲ့ drive အသစ်က IronWolf ဖြစ်ပါတယ်၊ သင်ခန်းစာယူထားပါတယ်) - လည်ပတ်နေတဲ့ array တစ်ခုထဲမှာ drive တစ်ခုဆုံးရှုံးသွားသလိုပဲ ကြောက်စရာကောင်းတာက အဲဒါကို အစားထိုးဖို့အတွက် မှန်ကန်တဲ့လုပ်ထုံးလုပ်နည်းကို မသိရင် ပိုတောင်ကြောက်စရာကောင်းပါတယ်။ mdadm array တွင် မအောင်မြင်သော drive တစ်ခုကို အစားထိုးရန် ပထမဆုံးအကြိမ်မဟုတ်သော်လည်း ကံကောင်းထောက်မစွာပင် သင့်လျော်သော command များကို ရှာဖွေရလေ့ရှိသည်မှာ အလွန်ရှားပါးပါသည်။ ဤတစ်ကြိမ်တွင် ကျွန်ုပ်သည် ကျွန်ုပ်၏ကိုယ်ပိုင်လမ်းညွှန်စာအုပ်ငယ်ကို အနာဂတ်အတွက် ကိုးကားရန် ဆုံးဖြတ်ခဲ့သည်။

ထို့ကြောင့် ပထမဆုံးအနေဖြင့် mdadm မှ dreaded fail event e-mail ကိုရသောအခါ၊ drive ပျက်သွားသည်ကို အထောက်အထားပြရန် လိုအပ်ပါသည်။ ဟုတ်ပါတယ်၊ ၎င်းသည် သင့်အား စက်၏အမည်ကို ပြောပြလိမ့်မည် (ကျွန်ုပ်၏ကိစ္စတွင် /dev/sdf) ကိုပြောပြလိမ့်မည်၊ သို့သော် စက်စတင်ဖွင့်သောအခါတွင် အဆိုပါအမည်များသည် ပြောင်းလဲနိုင်သောကြောင့် အမှန်တကယ်ဖြစ်နိုင်သော Physical Drive သည် မည်သည့်အရာဖြစ်သည်ကို ရှင်းရှင်းလင်းလင်းမသိရပေ။

မည်သည့်စက်ပစ္စည်းအမည်ကို ပျက်ကွက်ခဲ့သည်ကို သင်ပင်မသေချာပါက၊ သိရှိရန် အောက်ပါ command ကိုသုံးနိုင်သည် ( /dev/md0 ကို သင်၏ RAID စက်ဖြင့် အစားထိုးပါ)။

ကျွန်တော်ပြောခဲ့သလိုပဲ၊ ဒါက /dev/sdf ဖြစ်တယ်၊ အဲဒါကို ဆက်ကြည့်ရအောင်။

ထို့နောက် ဤ command ကိုထုတ်ခြင်းဖြင့် မအောင်မြင်သော drive ၏ နံပါတ်စဉ်ကို သင်ရှာဖွေနိုင်သည်-

(smartctl ကို ရှာမတွေ့ပါက၊ သင်သည် Ubuntu တွင် smartmontools ပက်ကေ့ဂျ်ကို ထည့်သွင်းရန် လိုအပ်သည်)

ထို့နောက် မည်သည့်အရာသည် ပျက်ကွက်ခဲ့သည်ကို သိရှိနိုင်ရန် နံပါတ်စဉ်နံပါတ်များကို drive များရှိ ရုပ်ပိုင်းဆိုင်ရာအညွှန်းရှိ အမှတ်စဉ်နံပါတ်များနှင့် နှိုင်းယှဉ်နိုင်သည်။

ဒါပေမယ် ဒီတစ်ခါတော့ ငါသိပ်ကံကောင်းတာမဟုတ်ဘူး။ Drive သည် လုံးဝသေဆုံးသွားပြီး SMART သို့မဟုတ် နံပါတ်စဉ်အပါအဝင် အခြားဒေတာများကို ပံ့ပိုးပေးရန်ပင် ငြင်းဆိုခဲ့သည်။

ကျွန်ုပ်သည် ဆာဗာသို့ ရုပ်ပိုင်းဆိုင်ရာဝင်ရောက်ခွင့်ရှိသောကြောင့် (သင်ကိုယ်တိုင်ရုပ်ပိုင်းဆိုင်ရာဒရိုက်ကိုအစားထိုးမည်ဆိုပါက သင်အမှန်တကယ်လိုအပ်သည်ဟု ယူဆပါ ;-)) ဒစ်ပျက်သွားသောအခါတွင် ဆာဗာ သည် အမှန်တကယ်လည်ပတ်နေပါသည် (RAID-6 ၏ကျေးဇူးကြောင့် ဆက်လက်လည်ပတ်နေနိုင်သည်)၊ ကျွန်ုပ်သည် အမှန်တကယ်ပင် မူလပုံစံဖြင့်သွားခဲ့သော်လည်း အမှန်တကယ်တွင် အလွန်ထိရောက်ပြီး သိသာထင်ရှားသော၊ ဖိုင်ကြီးတစ်ခုကို HDD ဆာဗာသို့ ရိုးရိုးကူးယူခြင်းနည်းလမ်းကို မကြည့်ခဲ့ပါ။ စက္ကန့်အနည်းငယ်အတွင်းမှာပဲ တရားခံကို ဖော်ထုတ်နိုင်ခဲ့ပါတယ်။

ယခု၊ ရုပ်ပိုင်းဆိုင်ရာဒရိုက်ကို မဆွဲထုတ်မီ၊ ဤအမိန့်ကို ထုတ်ပြန်ခြင်းဖြင့် (စက်အမည်များကို သင့်ကိုယ်ပိုင်အဖြစ် သင့်လျော်သလို အစားထိုးပါ)။

အောင်မြင်သောအခါတွင်၊ mdadm သည် ဒရိုက်ကို "ဟော့ဖယ်" ဟုပြောသော စာဖြင့် စာပြန်လိမ့်မည်၊ အကြောင်းမှာ၊ အကြောင်းမှာ၊ virtual raid device သည် ထိုအချိန်တွင် အမှန်တကယ်လည်ပတ်နေသောကြောင့်ဖြစ်သည်။

အကယ်၍ ၎င်းသည် "စက်ပစ္စည်း သို့မဟုတ် အရင်းအမြစ်အလုပ်များ" နှင့်ဆင်တူသော error message ဖြင့်ပျက်ကွက်ပါက mdadm သည် အမှန်တကယ်တွင် လုံးဝပျက်ကွက်စေရန် drive ကို စာရင်းမသွင်းထားခြင်းဖြစ်နိုင်သည်။ ၎င်းကိုပြုလုပ်ရန်၊ ဤအမိန့်ကိုထုတ်ပါ (တစ်ဖန်၊ သင့်ကိုယ်ပိုင်ကိရိယာအမည်များကို သင့်လျော်သလို အစားထိုးရန် မမေ့ပါနှင့်)

၎င်းနောက်၊ သင်သည် ယခင် command ဖြင့် စက်ပစ္စည်းကို array မှ ဖယ်ရှားနိုင်ရပါမည်။

ယခု drive ကိုအမှန်တကယ်အစားထိုးရန်အချိန်ဖြစ်သည်။ အကယ်၍ သင်သည် အမှန်တကယ် ပင်၊ သင့်စက်နှင့် controller သည် hot swapping ကို ပံ့ပိုးပေးသည်ဆိုပါက၊ စက်ကို မပိတ်ဘဲ သင်လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် သင်အမှန်တကယ်သိရှိနိုင်သော စစ်မှန်သော၊ သင့်လျော်သော ဆာဗာဟာ့ဒ်ဝဲပေါ်တွင် လုပ်ဆောင်နေသော အရေးကြီးသော ထုတ်လုပ်မှုစနစ်များကို ဆက်လက်လုပ်ဆောင်ရန် နည်းလမ်းဖြစ်လိမ့်မည်။ ကျွန်ုပ်၏အိမ်သုံးဖိုင်ဆာဗာသည် SATA ပေါက်များကိုပိုမိုပံ့ပိုးပေးရန်အတွက် PCIe အပေါက်များရှိ Semi-noname SATA ထိန်းချုပ်ကိရိယာအချို့ပါရှိသော စားသုံးသူအဆင့် desktop motherboard ကို အခြေခံထားသည်။

SATA သည် ယေဘုယျအားဖြင့် hot swapping ကို ပံ့ပိုးပေး သင့် သော်လည်း ဤတပ်ဆင်မှုတွင် ကျွန်ုပ်သည် မည်သည့်အရာကိုမျှ အန္တရာယ်မပြုတော့သောကြောင့် drive ကို အစားထိုးစဉ် စက်ကို ပိတ်ရန် ရွေးချယ်ခဲ့သည်။

ထိုသို့မလုပ်ဆောင်မီ၊ ပျက်စီးနေသော RAID array ကြောင့် Ubuntu သည် ၎င်းအား နောက်လာမည့် boot တွင် အလိုအလျောက် တပ်ဆင်ရန် မကြိုးစားနိုင်စေရန်အတွက် ဝင်ရောက်စီးနင်းသည့်ကိရိယာကို /etc/fstab ဖိုင်တွင် မှတ်ချက်ထုတ်ရန် အကြံဥာဏ်ကောင်းတစ်ခုဖြစ်သည်။ ၎င်းသည် desktop စနစ်ဖြစ်ပါက ပြဿနာကြီးကြီးမားမားမဟုတ်နိုင်သော်လည်း၊ ကျွန်ုပ်သည် မော်နီတာ သို့မဟုတ် ကီးဘုတ်မချိတ်ဘဲ ဤဆာဗာကို ခေါင်းမတပ်ဘဲ လုပ်ဆောင်နေသောကြောင့် အနည်းငယ်လုပ်ရပေလိမ့်မည်။

တောက်ပြောင်သော drive အသစ်ဖြင့် စက်ကို boot လုပ်ပြီးနောက်၊ ၎င်းကို သိရှိရန် lsblk သို့မဟုတ် အခြားနည်းလမ်းအချို့ကို အသုံးပြုပါ။ တခြားဘာကိုမှ မပြောင်းရသေးရင်၊ သင်အစားထိုးလိုက်တဲ့ drive နဲ့ နာမည်တူ (ဒါပေမယ့် သေချာပေါက် တော့ မဟုတ်ပါဘူး) ဖြစ်နိုင်ပါတယ် ။ ငါ့ကိစ္စမှာ၊ ဒါကြောင့် အသစ်ကို /dev/sdf လို့လည်း ခေါ်တယ်။

ကျွန်ုပ်၏ array သည် ရုပ်ပိုင်းဆိုင်ရာ စက်ပစ္စည်းများထက် အပိုင်းလိုက်များကို အခြေခံထားသောကြောင့်၊ ၎င်းတို့သည် အတိအကျတူညီကြောင်းသေချာစေရန်အတွက် အခန်းကန့်ဇယားကို အလုပ်ဒရိုက်တစ်ခုမှ drive အသစ်သို့ ကူးယူရန် လိုအပ်ပါသည်။ ၎င်းအစား သင့် array ကို ရုပ်ပိုင်းဆိုင်ရာ စက်များတွင် အသုံးပြုပါက၊ ဤအဆင့်ကို ကျော်သွားနိုင်ပါသည်။

ဤရည်ရွယ်ချက်အတွက် sgdisk ကိုအသုံးပြုပြီး partition table ကို /dev/sdc မှ /dev/sdf သို့ကူးယူပါသည်။ သင့်ကိုယ်ပိုင်နှင့် ကိုက်ညီစေရန် စက်အမည်များကို အစားထိုးရန် သေချာပါစေ။

ဤနေရာတွင် မှာယူမှုကို သတိပြုပါ - "to" drive ကို ဦးစွာ စာရင်းပြုစုပါ။ ဒါကငါ့အတွက်နည်းနည်းတန်ပြန်အလိုလိုသိနိုင်ပေမယ့် array မှာနောက်ထပ် drive ချို့ယွင်းချက်မရရှိနိုင်ကြောင်းသေချာအောင်လုပ်ပါ ;-)

ထို့နောက် UUID ပဋိပက္ခများကို ရှောင်ရှားရန် ဒရိုက်အသစ်အတွက် UUID အသစ်များကို ထုတ်လုပ်ပါ-

ယခု နောက်ဆုံးတွင် array တွင် drive အသစ်ကို ထည့်ပြီး ပြန်လည်တည်ဆောက်သည့်ပါတီကို စတင်ရန် အချိန်ကျရောက်လာပြီဖြစ်သည်။ (အိုကေ၊ ဒါဟာ ပါတီပွဲမဟုတ်ဘူး၊ တကယ်ကို နှေးကွေးပြီး တုန်လှုပ်စရာကောင်းတဲ့ လုပ်ငန်းစဉ်တစ်ခုပါပဲ၊ ဒီအချိန်မှာ ပျက်ကွက်တဲ့ နောက်ထပ် drive တစ်ခုကို မလိုချင်ပါဘူး။ ဘီယာက အထောက်အကူဖြစ်နိုင်ပေမယ့်)

ဘာပဲဖြစ်ဖြစ်၊ array တွင် drive အသစ်ထည့်ရန်၊ ဤ command ကိုထုတ်ပါ (တစ်ဖန်၊ စက်အမည်များကို သင့်ကိုယ်ပိုင်ဖြင့် အစားထိုးရန် သေချာစေပါ)

အားလုံးအဆင်ပြေပါက၊ drive ကို array တွင်ထည့်သွင်းမည်မဟုတ်ပါ။ ပုံမှန်အားဖြင့် ၎င်းကို "ပူသောအပိုပစ္စည်း" အဖြစ် အမှန်တကယ်ထည့်ထားကြောင်း ကျွန်ုပ်ယုံကြည်သည်၊ သို့သော် ဤ array သည် disk (မအောင်မြင်သောတစ်ခု) ပျောက်ဆုံးသွားသောကြောင့် ၎င်းကိုချက်ချင်းအသုံးပြုပြီး ပြန်လည်တည်ဆောက်ခြင်းလုပ်ငန်းစဉ်စတင်မည်ဖြစ်သည်။

ဤကဲ့သို့ စောင့်ကြည့်နိုင်သည်-

၎င်းသည် အချိန်အနည်းငယ် ကြာလိမ့်မည်; ကျွန်ုပ်၏ နိမ့်ပါးသော ဆာဗာတွင် (စားသုံးသူအဆင့် ဟာ့ဒ်ဝဲနှင့် ဒက်စတော့ဒရိုက်များပေါ်တွင် အခြေခံ၍ ၎င်းသည် 100 MB/sec အောက်တွင်သာ ရောက်ရှိနိုင်သည် ။ ၎င်းသည် RAID-6 ဖြစ်သည်ကို သတိပြုပါ၊ ထို့ကြောင့် ပြန်လည်တည်ဆောက်ခြင်းနှင့် ပတ်သက်သော တူညီသော တွက်ချက်မှုများစွာ ရှိပါသည်။ RAID-10 သည် ပိုမိုမြန်ဆန်မည် ဖြစ်သည်။ ဤစက်တွင် AMD A10 9700E quad core CPU ပါရှိသည် (၎င်းသည် အလွန်မြန်ဆန်သော စွမ်းအင်သက်သာသောမော်ဒယ်ဟု အဓိပ္ပာယ်ရသော "E" သည် သင့်အား မျှော်လင့်ရမည့်အရာကို စိတ်ကူးတစ်ခုပေးရန်အတွက်သာဖြစ်သည်။ ကျွန်ုပ်၏ စနစ်ထည့်သွင်းမှုတွင် 8 TB ဒရိုက်ဘာ ကိုးခုဖြင့် ပြန်လည်တည်ဆောက်မှု အပြည့်အစုံမှာ 24 နာရီကျော်သာ ကြာပါသည်။

ပြန်လည်တည်ဆောက်နေစဉ်အတွင်း၊ သင်သည် ဖိုင်စနစ်အား ခင်းကျင်းပေါ်တွင် တပ်ဆင်နိုင်ပြီး သင်ဆန္ဒရှိပါက ၎င်းကို ပုံမှန်အတိုင်းအသုံးပြုနိုင်သော်လည်း ၎င်းကို ပြီးမြောက်သည်အထိ ပြန်လည်တည်ဆောက်ခြင်းတွင် ထားခဲ့လိုပါသည်။ Drive တစ်ခုပျက်သွားရင် နောက်တစ်ခုက မကြာခင်မှာ လိုက်လာနိုင်ပါတယ်၊ ဒါကြောင့် အဲဒီကာလအတွင်းမှာ နောက်ထပ် drive တစ်ခု ပျက်မသွားစေချင်တဲ့အတွက် အမြန်ဆုံး ပြန်လည်တည်ဆောက်မှုကို မြန်မြန်ဆန်ဆန် လုပ်ဆောင်စေချင်ပါတယ်။ ထို့ကြောင့်၊ တင်းကြပ်စွာမလိုအပ်သောအခြား IO နှင့်ဝန်ထုပ်ဝန်ပိုးမဖြစ်ပါစေနှင့်။

ပြီးသည်နှင့်၊ ၎င်းကို သင်၏ /etc/fstab ဖိုင်သို့ ပြန်ထည့်ပါ၊ ပြန်ဖွင့်ပြီး သင့်ဖိုင်များကို ခံစားကြည့်ပါ :-)