[EMAIL PROTECTED] said:
> Right. Cache memory on the drive is not a problem. Cache memory on a
> controller card may be, and in the absence of SCSI reservations, you
> need to make sure that the reads are coming from the disk and not the
> controller at least for the quorum partition.
Now I'm really confused.
The Host Bus Adapter (HBA) which sits in the computer and drives the shared
bus *never* uses it's internal memory for caching device blocks (except as
part of command/data transfer), for precisely this reason.
The Array controller, which usually sits between the shared bus and the drives
comprising the array, sees all the updates from all initiators and therefore
never has a stale cache.
As you say, the individual drives also have a cache but that's not a problem
since they see all of the read/write requests anyway.
The only case you should have a problem is with a solution based on PCI RAID
cards connected to a JBOD (like the AMI cluster RAID card, or the DPT
equivalent for fibre channel). I would be astonished if these cards are
allowed to cache data on board when in cluster mode. However, if it speaks a
reasonable SCSI dialect, turn off the WCE (Write Cache Enable) and turn on the
RCD (Read Cache Disable) bits of the caching mode page which should make it
behave.
> If we can safely assert that controller cards just won't cache reads,
> then it's a non-issue.
Controller cards that sit inside the array are essentially SCSI devices and
are governed by the standards which allow them to cache both reads and writes.
Controller cards in the host are outside the scope of the standards so I would
bet you have to tailor your solution to the individual controller.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
