Newsgroup: it.comp.os.linux.iniziare
Titolo: RAID-software e dischi che "si spostano"

Ciao a tutti.
Nei miei recenti thread ho manifestato problemi sul RAID. Ho scoperto 
che /dev/md0, che dovrebbe essere costituito da /dev/sdb1 e /dev/sda1 
*non* ï¿œ cosï¿œ messo...
Ossia, i due dischi menzionati, ora si trovano su /dev/sdc1 ed /dev/sdd1
Come mai ï¿œ successo questo?
Come fare a ripristinare la situazione corretta?
Come evitare di "perdere" nuovamente la configurazione, quindi il RAID?
Grazie!

 sui dischi.
Niente smanacciamenti, � un server che nient'altro ha da fare che 
restare acceso e fare qualche trasferimento notturno di GB di dati.
Riepilogo qui la situazione:
storebox:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[0] sda1[2](F)
       976759936 blocks [2/1] [U_]
unused devices: <none>
Da qui si capisce che il device md0 � costituito da sdb1 ed sda1.
cfdisk sia sui singoli device (sda, sdb) che sulle partizioni (sda1, 
sdb1) mi dice "FATAL ERROR: cannot open disk drive".
Se per� lo faccio su sdc ed sdd, vedo una partizione per disco, di tipo 
"Linux Raid Autodetect" (cio� sono i miei dischi dell'array).
Ho anche per curiosit� provato mdadm:
storebox:~# mdadm --detail --scan
ARRAY /dev/md/0_0 metadata=0.90
Che diavolo succede? � possibile che i dischi SATA vengano "mappati" su 
sda, sdb, o sdc, sdd in base a quali altri periferiche sono gi� connesse 
sul bus? Cio�, sono per cos� dire "flottanti" in termini di /dev, quindi 
dovrei "fissarli" con un ID o simile?
Grazie...

 sui dischi.
In realta' credo fosse successo anche a me: quando l'array e' entrato in
linea, al primo riavvio dischi hanno cambiato nome (anche l'array in
effetti ha cambiato nome, avevo settato md0 ed e' diventato md127).
La cosa pero' non dovrebbe dare alcun problema: mdadm riconosce l'array
dall'ID del superblocco, che non cambia, quindi l'array dovrebbe essere
sempre riconosciuto correttamente (e' stato cosi' per me).
E in fstab uso lo UUID dell'array, cosi' anche quello non si lamenta quando
md0 diventa md127.
Pleg

Davide Bianchi ha scritto:
Allora, ieri sera sono riuscito a far rifunzionare l'array (menomale che 
non � /).
Molto probabilmente il mio rescan del bus SATA, ha fatto s� che i due 
dischi venissero riconosciuti nuovamente, per� spostati su sdd ed sdc 
poich� il Sistema vedeva come occupati sda ed sdb.
Ho smontato l'array (unmount e poi con mdadm stop), poi l'ho riattivato 
e tutto � andato liscio: ha iniziato a sincronizzare, questa volta per� 
su sdd ed sdc (ma poco conta, dato che dovrebbe essere riconosciuto ed 
attivato in base al superblocco presente sui dischi).
Stamane, invece, ricontrollo l'array e vedo che � "zoppo":
storebox:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd1[2](F) sdc1[0]
       976759936 blocks [2/1] [U_]
Di seguito la parte rilevante di /var/log/messages:
Dec  9 19:57:42 storebox kernel: [9814007.931087] md: md0 stopped.
Dec  9 19:57:42 storebox kernel: [9814007.931087] md: unbind<sdb1>
Dec  9 19:57:42 storebox kernel: [9814007.931087] md: export_rdev(sdb1)
Dec  9 19:57:42 storebox kernel: [9814007.931088] md: unbind<sda1>
Dec  9 19:57:42 storebox kernel: [9814007.931088] md: export_rdev(sda1)
Dec  9 20:03:17 storebox kernel: [9814368.203878] md: md0 stopped.
Dec  9 20:03:17 storebox kernel: [9814368.207882] md: bind<sdd1>
Dec  9 20:03:17 storebox kernel: [9814368.207882] md: bind<sdc1>
Dec  9 20:03:17 storebox kernel: [9814368.207882] md: kicking non-fresh 
sdd1 from array!
Dec  9 20:03:17 storebox kernel: [9814368.207882] md: unbind<sdd1>
Dec  9 20:03:17 storebox kernel: [9814368.207882] md: export_rdev(sdd1)
Dec  9 20:03:17 storebox kernel: [9814368.260678] raid1: raid set md0 
active with 1 out of 2 mirrors
Dec  9 20:07:40 storebox kernel: [9814655.720667] md: bind<sdd1>
Dec  9 20:07:40 storebox kernel: [9814655.741167] RAID1 conf printout:
Dec  9 20:07:40 storebox kernel: [9814655.741167]  --- wd:1 rd:2
Dec  9 20:07:40 storebox kernel: [9814655.741167]  disk 0, wo:0, o:1, 
dev:sdc1
Dec  9 20:07:40 storebox kernel: [9814655.741167]  disk 1, wo:1, o:1, 
dev:sdd1
Dec  9 20:07:40 storebox kernel: [9814655.747021] md: recovery of RAID 
array md0
Dec  9 20:07:40 storebox kernel: [9814655.747021] md: minimum 
_guaranteed_  speed: 1000 KB/sec/disk.
Dec  9 20:07:40 storebox kernel: [9814655.747021] md: using maximum 
available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Dec  9 20:07:40 storebox kernel: [9814655.747021] md: using 128k window, 
over a total of 976759936 blocks.
Dec  9 20:08:15 storebox kernel: [9814707.878129] kjournald starting. 
Commit interval 5 seconds
Dec  9 20:08:15 storebox kernel: [9814707.878129] EXT3-fs warning: 
checktime reached, running e2fsck is recommended
Dec  9 20:08:15 storebox kernel: [9814707.878129] EXT3 FS on md0, 
internal journal
Dec  9 20:08:15 storebox kernel: [9814707.878129] EXT3-fs: recovery 
complete.
Dec  9 20:08:15 storebox kernel: [9814707.878129] EXT3-fs: mounted 
filesystem with ordered data mode.
Dec 10 01:31:48 storebox kernel: [9839374.628366]          res 
40/00:00:09:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Dec 10 01:31:53 storebox kernel: [9839381.037719] ata1: link is slow to 
respond, please be patient (ready=0)
Dec 10 01:31:58 storebox kernel: [9839386.838864] ata1: device not ready 
(errno=-16), forcing hardreset
Dec 10 01:31:58 storebox kernel: [9839386.838877] ata1: soft resetting link
Dec 10 01:32:04 storebox kernel: [9839392.909160] ata1: link is slow to 
respond, please be patient (ready=0)
Dec 10 01:32:08 storebox kernel: [9839398.662492] ata1: soft resetting link
Dec 10 01:32:14 storebox kernel: [9839404.846669] ata1: link is slow to 
respond, please be patient (ready=0)
Dec 10 01:32:18 storebox kernel: [9839410.325862] ata1: soft resetting link
Dec 10 01:32:24 storebox kernel: [9839416.074449] ata1: link is slow to 
respond, please be patient (ready=0)
Dec 10 01:32:54 storebox kernel: [9839450.625400] ata1: soft resetting link
Dec 10 01:32:59 storebox kernel: [9839456.672931] ata1.00: disabled
Dec 10 01:32:59 storebox kernel: [9839456.672931] ata1: EH complete
Dec 10 01:32:59 storebox kernel: [9839456.672931] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 01:32:59 storebox kernel: [9839456.672931] raid1: Operation 
continuing on 1 devices.
Dec 10 01:32:59 storebox kernel: [9839456.672931] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 01:32:59 storebox kernel: [9839456.673454] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 01:32:59 storebox last message repeated 2 times
Dec 10 01:32:59 storebox kernel: [9839456.673454] md: super_written gets 
error=-5, uptodate=0
Dec 10 01:32:59 storebox kernel: [9839456.696934] md: md0: recovery done.
Dec 10 01:32:59 storebox kernel: [9839456.908927] RAID1 conf printout:
Dec 10 01:32:59 storebox kernel: [9839456.908927]  --- wd:1 rd:2
Dec 10 01:32:59 storebox kernel: [9839456.908927]  disk 0, wo:0, o:1, 
dev:sdc1
Dec 10 01:32:59 storebox kernel: [9839456.908927]  disk 1, wo:1, o:0, 
dev:sdd1
Dec 10 01:32:59 storebox kernel: [9839456.908927] RAID1 conf printout:
Dec 10 01:32:59 storebox kernel: [9839456.908927]  --- wd:1 rd:2
Dec 10 01:32:59 storebox kernel: [9839456.908927]  disk 0, wo:0, o:1, 
dev:sdc1
Dec 10 08:29:17 storebox kernel: [9869328.364121] program smartctl is 
using a deprecated SCSI ioctl, please convert it to SG_IO
Dec 10 08:29:17 storebox kernel: [9869328.364274] program smartctl is 
using a deprecated SCSI ioctl, please convert it to SG_IO
Dec 10 08:29:17 storebox kernel: [9869328.511284] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 08:29:17 storebox kernel: [9869328.513667] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 08:29:28 storebox kernel: [9869341.668168] program smartctl is 
using a deprecated SCSI ioctl, please convert it to SG_IO
Dec 10 08:29:28 storebox kernel: [9869341.668168] program smartctl is 
using a deprecated SCSI ioctl, please convert it to SG_IO
Dec 10 08:29:28 storebox kernel: [9869341.712167] sd 1:0:0:0: [sdd] 
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 10 08:29:28 storebox kernel: [9869341.712167] __ratelimit: 23 
messages suppressed
-----------------
Che diavolo pu� essere successo?
Come controllo entrambi i dischi se hanno errori? Io l'avevo fatto ieri 
(sul disco che risultava "offline") da un PC con il tool della Western 
Digital per controllare i dischi e mi dava "OK"... :-/
Grazie...