On Thu, Jun 15, 2000 at 10:45:12AM -0400, Ricky Beam wrote:
> On Thu, 15 Jun 2000, Kurt Garloff wrote:
> >No. And it would be cleared by the exception handling as sooner or later you
> >would get a SCSI reset because of the reservation conflicts ...
>
> While linux certainly would go down this path. NO SCSI HOST/BUS/DEVICE
> SHOULD !_EVER_! BE RESET DUE TO A RESERVATION CONFLICT. The fact that
> linux will see a reservation conflict as a reset canidate error is just
> #^#%% wrong. Obviously someone either failed to read an entire section
> of the SCSI-2 spec or is just too lazy to care about proper operations.
Don't be unfair! The error handling strategy of Linux SCSI stack is
non-optimal and this has been repeated again and again on l-scsi. The new
error handling code of l-2.2 is much better, but only few drivers use it.
BTW, I'm not even sure what happens in case of device reservation: The disk
returns this error (RES CONFLICT), and I did not check, whether this error
will be passed back to userspace as an IO error or if the command will be
retried, aborted ... Experience just tells me, that Linux gets too easily
into doing a reset.
As we don't have some model for the state of a SCSI device, there is no
general way to redo the reservation after a RESET occured.
(The drivers, e.g. do redo sync and wide nego on a reset, as they have this
state info.)
The problem with the SCSI code in Linux is, that it is rather old and was
designed to make the devel of drivers for the old ISA-DMA SCSI host adapters
rather easy. It suceeded to do so, BTW.
Nowadays, one would probably design it according to CAM. BSD did that switch
some time ago, IIRC.
But: The SCSI subsys of Linux has been finetuned, tweaked, ... etc. to work
rather well in practice, so nobody wants to exchange the current system to a
new one, where one would need to redo almost everything, including low-level
drivers.
> >> Or is this handled via some other mechanism?
> >> + Driver(s) responsible for handling any+all multi-initiator issues.
> >> + LVM, clustering, or somesuch?
> >
> >No.
> >Of course, you can design software to handle this ...
>
> There is no page cache sync between machines. Thus, who ever flushes their
> change(s) to disk last wins.
If you are looking for a userspace only solution, then you would need to
discard the cache ioctl(FLUSHB), when somebody else writes to the disk and
signals you.
This yields extremely poor performance, when you often have writes, so this
is only a quasi-read-only solution.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
