Subject:
Re: Recovering from a lost disk
Date:
Mon, 25 Oct 1999 12:06:09 -0200
From:
Leandro Dybal Bertoni <[EMAIL PROTECTED]>
Organization:
Uni�o Paulista de Espeleologia
To:
Marc Haber <[EMAIL PROTECTED]>
References:
1 , 2 , 3
Marc Haber wrote:
>
> On Sat, 23 Oct 1999 18:26:04 -0200, you wrote:
> >[your prompt]#raidhotadd /dev/md0 /dev/sdc6
> >[your prompt]#raidsetfaulty /dev/md0 /dev/sdd6
> >[your prompt]#raidhotremove /dev/md0 /dev/sdd6
>
> |$ pwd
> |/home/mh/devel/userspace/raidtools-0.90
> |$ ls raidhotad* raidsetfault* raidhotremov*
> |ls: raidhotad*: No such file or directory
> |ls: raidsetfault*: No such file or directory
> |ls: raidhotremov*: No such file or directory
> |$ ls -d ../raidtools-*
> |../raidtools-0.90 ../raidtools-19990824-0_90_tar.gz
> |$
>
> These tools don't seem to be included with the raidtools snapshots.
> Where do I get them from?
They are symbolic links of raidstart (they wouldn't be in the raidtools
source directory after a 'make', but 'make install' should create them
in /sbin)
> >> 2)
> >> What happened on the second disk "failure" when the system became
> >> unuseable? Isn't it RAID's purpose to keep such things from happening?
> >> I'd have expected the kernel to notice that the disk is dead for good
> >> and to stop trying to access it over and over. It worked the first
> >> time!
> >
> >If I remember from another time this was asked, that's the SCSI layer
> >trying _very_ hard to get some answer from your disconnected disk...
>
> How do I keep the SCSI layer from doing this? Is it a bug in the NCR
> driver?
I'm out of my depth here, I'm just parroting what I remember from a
previous thread.
It seems the SCSI drivers try very hard to get whatever commands where
passed them done, and the md driver would know that one failed only when
the low level driver gave up. One solution would be to make the low
level driver not try so hard, but return an error sooner, but perhaps
you wouldn't want that always: that could be fine if the disk was part
of a raid1 or raid5, where you have some redundancy. There was some talk
of passing a parameter to the lower layers to tell them how hard to try,
but that means changing a lot of things in the lower layers. From a bit
of lurking on linux-kernel, it seems the SCSI layer is undergoing some
code clean up now, and is expected to get a major rewrite in 2.5
> This behavior can cause great additional problems because I might have
> to reboot to get my system back up.
Yep. But people here say that most of disks would die much more
gracefully than when you pull the power/data cable, so the raid driver
would get a chance to mark the disk failed without all that noise. I
sure hope so. But yes, you could have to raidhotremove the disk and tell
the scsi layer to drop it ('echo "scsi remove-single-device a b c d
">/proc/scsi/scsi' would do the trick (a=adapter ID, b=chanel, c=device
ID, d=LUN)if the disk isn't being used anymore), and worst case you
would have to reboot.
> When the failed disk has not been
> replaced during the downtime and the drive electronics are bad so that
> the drive is not recognized on boot-up, all disks that have higher IDs
> move back one notch in the /dev/sd* scheme. This might prevent the
> degraded RAID from being recognized correctly and it actually even
> might prevent conventional partitions from being found since their
> name changed. This reminds me of the drive letter problem that DOS
> operating systems are cursed with.
>
> Is there a standard way to cope with that? There is a program called
> scsidev that can be used to create symlinks under /dev/scsi that are
> guaranteed to always point to the same disk, but it fails when
> multiple disks of the same model and firmware release are used because
> the different disks can't be distinguished. Additionally, scsidev
> segfaults on my Debian system.
>
> Is there a tool that writes identification numbers to the disks
> themselves and uses these numbers to identify the disks even if their
> order in the system has been altered?
If you create the arrays with persistent superblocks (default for
raidtools 0.90), have autodetection of raid built into your kernel (or
as a module in a initrd) and your raid partitions are of type fd
(instead of 83), you will not need to worry about that too much: you
will get the right partitions in the right order into your array even if
the disks "change name".
But if you don't have autodetect, etc. , then your array is started by
raidstart in a init script, and I think you would need an up to date
raidtab (I'm not sure what would happen if you had persistent
superblocks in the raid partitions and tried to raidstart with a
diferent raidtab).
You need an up to date raidtab if you run mkraid to write new
superblocks into the raid partitions though.
Cheers,
Leandro
