[EMAIL PROTECTED] said:
> Right --- that's exactly why I'm bringing this up, because I suspect
> that the default behaviour is _not_ cluster-safe in all conditions.
> I'd rather have an answer from somebody with more knowledge of just
> how modern PCI SCSI controllers behave wrt. read caching.
Modern PCI SCSI host bus adapters do not do block caching (indeed they rarely
translate SCSI commands at all). That's not to say the driver couldn't
program them to: a large number are scripts based in some way and could
theoretically be programmed to do block caching, but it would be a waste of
valuable resources.
The PCI RAID cards are a different class of beast. I've got a colleague who
is investigating a so called host based RAID cluster, I can report back when
it is complete. However, the thing to bear in mind is that most PCI RAID
cards don't expect to meet another RAID card on the internal bus. However
(here begins opinion, not fact), even those that can be set to behave
correctly, I suspect they're going to want to partition up the array so that
the LUNs are locked to individual cards since RAID state sharing protocols are
a big pain to implement. They won't therefore be usable in the shared LUN
environment you need for a quorum disc.
Regardless, since genuine HBAs function correctly, and you should be able to
detect the suspect host based RAID cards and alter their caching parameters
accordingly at boot time, do you still need to control the FUA bit?
If it helps you to feel happier about quorum disc implementations with
standard SCSI HBAs, all the Symbios 53cxxx series and the aic7xxx series
controllers work fine with the NCR Distributed Lock Manager which uses a
shared parition to implement a decker lock based quorum disc without
influencing the SCSI caching mechanisms.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
