[netmaster]

Mõtlesin kas postitada siia või Linux'i alafoorumisse, aga pigem proovin siin õnne.

Olude sunnil teen elu esimest softiraidi ja sellega seoses mängin läbi igasuguseid traagilisi stsenaariume.

Tegin sellise katse, justkui ketas läheks fataalselt rikki, ehk kiskusin ta poole sõidu pealt masinast välja.
Tagasi pistes (sama ketas muutmaul kujul), ta millegipärst ei olnud enam sdb, vaid sdc. Teist ja kolmandat korda ikka sdc. Mul on selline mulje, et see sdb on kuidagi alles seal, kuigi ei paista kuskilt. Iseenesest ei ole see eriline tragöödia, sdc raidi tagasi läks jne, kuid kui sa iialgi ei tea mis su ketta nimi täna olla võib, tekitab see mõningast segadust. Eriti veel siis, kui peale rebooti oli ta jälle tagasi sdb.

Kas on kuidagi võimalik sundida see ketas uuesti tagasi sdb'ks ilma reboodita?
Või kuidas kaotada masinast jäljed füüsiliselt väljatõmmatud kettast, et "uus" sisse pistetud ketas saaks sama nime?
Otsisin netist ka igasuguseid variante, kuid kuna /dev/sdb on kadunud, siis enamus seal pakutud lahendustest on kasutud.

Linux on CentOS ...

[Dogbert]

Kui kasutad partitsioonide identifitseerimiseks UUID-sid kettanimede asemel, siis pole mingit vahet, millise nime süsteem talle annab - sda, sdb, sdc või sdx. Debian läks UUID-dele by default üle paar versiooni tagasi, CentOS-i ei ole kahjuks näppinud, aga kui seal UUID-sid ei kasutata vaikimisi, siis kindlasti oleks neid kasutada võimalik.
Ühe vanema Debianiga olin ka mitmeid aastaid tagasi samamoodi hädas - kord on üks ketas sda ja teine sdb, järgmine kord on kohad vahetunud jne. Kolme ketta ja kahe kontrolleriga oli veel hullem žongleerimine. UUID-d on selle probleemi täielikult elimineerinud.
Tookord ma uurisin ka, et kas on kuidagi võimalik neid nimesid sama ketta külge saada iga kord, aga jõudsin lõpuks järeldusele, et nimed sõltuvad vaid sellest, millises järjekorras kernel need kettad bootimisel üles leiab. See viimane aga on seda juhuslikum, mida rohkem sul on kontrollereid ja kettaid.

Näiteks Debian wheezy mdadm.conf näeb mul hetkel välja selline:
(kaks füüsilist ketast, eraldi /, /boot, /usr, /var, /tmp ja /home ning swap)

Spoiler

# mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions #/dev/sd[ab][125] #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 root # definitions of existing MD arrays ARRAY /dev/md0 UUID=764951f0:6e5748d2:c6230241:f316bc95 ARRAY /dev/md6 UUID=954f9956:27333cda:c6230241:f316bc95 ARRAY /dev/md1 UUID=ef89b1eb:1ab90efa:c6230241:f316bc95 ARRAY /dev/md2 UUID=68cbd282:bad0e7eb:c6230241:f316bc95 ARRAY /dev/md3 UUID=2867cabb:f884a1d4:c6230241:f316bc95 ARRAY /dev/md4 UUID=e9318043:c9847fed:c6230241:f316bc95 ARRAY /dev/md5 UUID=34cf7c08:1bf96e8b:c6230241:f316bc95 # This configuration was auto-generated on Mon, 21 Feb 2011 14:28:52 +0200 # by mkconf 3.1.4-1+8efb9d1

Pole vahet, mis ketta nimi parajasti on. Kui tahad iseendale selgust, siis pead kuidagi teisiti need kettad ära tundma, kasvõi seerianumbri järgi, sest seadmenimi on Linuxis ketastel vägagi juhuslik nähtus. RAID massiivide nimed on ju püsivad, nii et pole nagu olulist vahet, mis nimega kettad selles osalevad.

Kuidas "surnud" ketas süsteemist elimineerida ilma kernelit uuesti käivitamata või kettakontrolleri draiverit uuesti laadimata - ei tea tõesti. Kahtlen, kas see ongi üldse võimalik.

[netmaster]

jah, ma tean seda UUID asja. Paraku paljud programmid ei kasuta UUID'si, sealjuures ka mdadm.
Mind pigem teeb murelikuks hüpoteetiline olukord, kus masina uptime on 2 aastat ja mõlemad peegli kettad on (võibolla mitu korda) vahetatud. Kui mdadm nüüd raporteerib, et /dev/sde on rikkis, siis milline ketas see on? Kui kõik deviced on sassis, siis äkki ma raban viimase töötava ketta sangast kinni ja kisun ta välja. Igal juhul oleks parem, kui ketaste nimed oleks koguaeg samas järjekorras, et sahtlitele saaks numbrid/nimed peale kleepida. Eriti jamaks läheb veel siis, kui kettaid on raidis suurem kogus.

[karu]

sda, sdb, jne link /sys/block/ kataloogis omab infot mis sata port on kasutusel, näiteks minul on

[Dogbert]

Eks ta enne ketta väljarabamist tahab ikka tasakaalukalt enne üle vaadata ja kontrollida, mida sealt välja rabada üldse.
Kui ketas on surnud, siis tõenäoliselt tema seerianumbrit enam hdparm ei näita, aga saab kontrollida allesjäänud elusate ketaste seerianumbreid.
Vaatad siis hdparm-iga töötava ketta seerianumbri ja teed kasvõi vildikaga vastavale kettale märgi, vaatad järgmise ja teed sellele märgi jne. Mis jääb märgita, selle tõmbad välja.
Võid ka lihtsa tsükli kirjutada kõigi ketaste seerianumbrite väljastamiseks, kui sul neid suurem ports on: sudo bash -c 'for disk in /dev/sd?; do echo "$disk $(hdparm -I $disk | grep Serial)"; done'
Siit järeldub, et seerianumbrid võiks ketastel olla nähtaval kohal - kasvõi ise paigaldatud lisakleepsu peal .

Mul endal õnneks siiani pole vaja olnud, aga eks ma umbes sedasi pean õnnetuse korral toimima.
_______________________

karu, SATA pordi järgi vaatamine on väga hea mõte. Siis võib muidugi seerianumbri asemel ketastele/sahtlitele SATA pordi numbrid peale kirjutada-kleepida.

[netmaster]

mnjah ...
Selle jutu peab muidugi kõrvataha panema, aga ma pigem lootsin, et kuidagi ikka saab tekitada olukorra, kus ketta tähis ei muutu. Teoreetiliselt peaks see ju siiski võimalik olema, sest USB pulkadel nad ei muutu, isegi kui poole kirjutamise pealt välja katkuda. Kui on näiteks sde, siis on täna sde ja homme ja iga pulk, mis suvalisse auku pistetakse. Arumaeisaa, mis seal siis vahet on, sama block device ju. Samamoodi on tegelikult ka SATA ketastega. Niikaua, kui ta raidi osa ei ole, niikaua pista sinna mistahes kettaid, mounti, loe ja kirjuta, unmounti, pane järgmine ketas, ning igakord on sama nimi. Kui ketas kutuurselt raidist eemaldada, pole samuti mingit probleemi, uus ketas on sama nimega. Peaks võibolla proovima mountitud SATA ketast välja katkuda ja vaatama, mis siis saab. Võibolla on see üldse mingi mdraid'i bug?

Sel softiraidil on veel veidrusi, niiet ma kulutan selle aja ja energia pigem rahakotti masseerimisele, ehk ikka ostab lõpuks normaalse kontrolleri ...

[karu]