Re: RAIDframe component replacement

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

> > But with scsictl detach/scan, I suppose?
 
> > But with SCA, I'm unsure, whether, after detaching sd0 (and sd1 still
> > there), a newly scanned sd will become sd0 or sd2?
> 
> I'm not sure either.  My guess would be that it would be sd2, but that
> is just a guess.

When I have done this in the past, I have done:

  raidctl -f /dev/sd0a raid0            # mark component as failed
  scsictl /dev/sd0c stop                # stop disk spinning (optional)
  scsictl /dev/scsibus0 detach 0 0      # detach old disk
    [remove old disk, insert new]
  scsictl /dev/scsibus0 scan any any    # attach new disk
  disklabel -i sd0                      # add/edit disklabel
  raidctl -R /dev/sd0a raid0            # rebuild raid

Replace with the relevant values for "sd0", "raid0", and "scsibus0" above.

The new disk gets the same ID as the old one.  With SCA, the SCSI ID is
part of the enclosure, and not set on the disk.

Occasionally, inserting the new disk has caused a SCSI bus reset, because I
couldn't guarantee that the bus would be idle when I changed disks.  This
might cause other disks to negotiate async transfers.  Either waiting, or
explicit:

  scsictl /dev/scsibus0 scan X 0

where X is the SCSI ID of the other disk restores the correct transfer speed.
(You don't want your other raid disk running async during the rebuild).

Note, that a disk isn't always labelled with the same number of sectors as
another of the same model.  Hopefully, the replacement has at least as many
sectors as the original.

Thanks,

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/