Alan Cox wrote:
>
> On Wed, 2002-10-09 at 15:46, Stephen Cameron wrote:
> > This patch adds the CCISS_RESCANDISK ioctl which is meant
> to be used in a
> > configuration like Steeleye's Lifekeeper. Two hosts
> connect to the storage,
> > one reserves disks. The 2nd will not be able to read the partition
> > information because of the reservations. In the event the
> 1st system fails,
> > the 2nd can detect this, (via special hardware + software
> typically) and then
> > take over the storage and rescan he disks via this ioctl.
> > Applies to 2.5.41 (after applying my prior 4 patches to 2.5.4[01] )
>
> Why not use the existing rescanning ioctls like BLKRRPART -
> what else is
> different to need a custom ioctl?
>
if i understand correctly, the BLKRRPART just does a rescan_partitions()
and does not do any INQUIRY and READ_CAPACITY to get the
capacity and geometry information again, as normally, this would
already be done.
This ioctl is meant for a failover type configuration where two hosts
have access to the storage. Host A does a scsi reservation of the storage,
preventing the Host B from being able to talk to it. So Host B can't do
the READ_CAPACITY successfully. (this is on purpose).
This ioctl is used upon failover. When Host B detects that Host A is failed,
Host B would make sure host A is_really_ dead, for example
by depriving it of power, and break the scsi reservation. Then it uses
this ioctl to get the geometry and capacity information and rescan
the partitions.
Maybe it should use 2 ioctls? One special one to get the geometry
and capacity info, and then the BLKRRPART ioctl to rescan partitions?
Hope that makes sense.
-- steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:31 EST