Veritas Volume Manager has a "virtual" device driver (vxio) which handles the
intermediary step between the actual device driver and the higher level.
This allows for some advanced RAID possibilities - if a write fails to
complete, the ioctl returns a value of -1... That way you can execute a
Veritfy_Write, which as data is written it is read back from each mirror
that was successfully written and is compared in a buffer. If the data from
any mirror doesn't match the data written then the flag is set for the
mirror, which can cause a multitude of things to happen, hot-spares to be
brought into play, hot-relocation, failing the disk, etc.
Of course Volume Manager abstracts the volumes to a much wider logical
volume structure, completely bringing things outside of device control
(although you can drill back into that if you need to), so that each drive
has its configuration located in a private region on the disk.
Micah
On Wed, 21 Mar 2001, Alan Cox wrote:
> > Umm. Isn't RAID implemented as the md device? That implies that it is
> > responsible for some kind of error management. Bluntly, the file systems
> > don't declare a file system kaput until they've retried the critical
> > I/O operations. Why should RAID5 be any less tolerant?
>
> File systems give up the moment they get an error. The actual device driver
> does the retries. This is done because only the driver or things like the scsi
> layer know about the right retry procedures for a given device - eg for a
> smart raid controller retrying is done by the card
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
