[EMAIL PROTECTED] said:
> SCSI reservation, where available, is a great tool for doing quorum
> assignment.
SCSI reservations are available now. The patches floating around on this list
(and folded into the redhat kernel 2.2.16-3) allow you to make, release and
break reservations using the SCSI generic driver. A true in-kernel
implementation would be better but at least these patches allow a user level
daemon to do everything that's needed (reservation maintenence, reservation
stealing detection etc).
> It doesn't solve the I/O fencing problem completely.
That depends on the implementation. SCSI-3 reservations do address
reservation sharing and extent based reservations. However, The only array I
know which supports these is the EMC (not a low cost solution).
> There are several problems here. One of the main problems which gets
> in the way of using SCSI reservation for true fencing is that
> reservation is typically implemented at the level of individual disks.
> You _can_ build a hardware raid array that supports reservation, but a
> lot of them don't. When you start building software constructs like
> LVM or soft raid on top, you lose access to the reservation facility.
Every true array I've tested under linux (ConSan, EMC and LSI) thus far
supports reservations. By "true" I mean implements the RAID in the array box.
So called host based arrays (which are really RAID cards connected to JBODs)
by and large don't.
> Right now, I don't think Linux ever uses the FUA (force unit access)
> bit in the SCSI commands it generates. SCSI folks, how easy would it
> be to get that bit exposed to the buffer cache layers for use by raw I/
> O? Without FUA being settable, a clustered SCSI configuration is not
> going to be able to work well in the presence of caching SCSI
> controllers. The use of SCSI reservation should not have this
> problem.
Correct, DPO and FUA bits are forced to zero by sd.c. To have them set
globally by a flag in the device structure would be easy. To do this on a per
request structure basis, you'd need an additional flag in the request
structure. All in all, not a big change. There are wrinkles: the 6 byte
commands don't support these bits so if you use them the storage better
support ten (or higher) byte commands.
Could you elaborate more on the problem you're trying to solve here? Using
cache memory on the drive can be extremely helpful for performance. If you're
worried about committed transaction loss on power fail they you might like to
consider the SYNCHRONIZE_CACHE command instead (you can use this via the
command ioctl without kernel changes).
James Bottomley
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
