Hello,
The change to add the SYNC_NV bit came with SBC-2 rev. 14 ( May 2004 ).
In SBC-2 rev. 13 ( March 2004 ) the bit was Reserved.
It looks like devices that don't support this bit should continue to
sync to media and ignore the fact that the bit is set, but, it was a
Reserved bit before rev. 14 and there could be devices that will post
check condition status when any Reserved bit is set.
The SPC-3 spec rev. 19 ( May 2004 ) is the first SPC-3 spec that added
the NV_SUP ( NV supported ) bit to Inquiry Vital Product Data page ->
86h byte 6 bit 1 ( NV_SUP ).
Before setting the SYNC_NV bit in commands, you should check that the
device reports supporting it by checking this Inquiry VPD page.
Also, the Synchronize Cache command is not the only command that changed
with the NV_SUP change, the FUA_NV bit was also added to the following
commands so that non-volitale cache is considered when this bit is set
in those commands;
READ(10) and larger
WRITE(10) and larger
XDWRITE all
XDWRITEREAD all
XPWRITE all
-Dave
===============
Bill Moore wrote:
On Tue, Aug 22, 2006 at 11:46:30AM -0700, Anton B. Rang wrote:
I realized just now that we're actually sending the wrong variant of
SYNCHRONIZE CACHE, at least for SCSI devices which support SBC-2.
SBC-2 (or possibly even SBC-1, I don't have it handy) added the
SYNC_NV bit to the command. If SYNC_NV is set to 0, the device is
required to flush data from any non-volatile cache to the storage
medium. If SYNC_NV is 1, however, the device is only required to
ensure that data in any volatile caches is flushed to non-volatile
cache if present.
We should be setting SYNC_NV for devices which support SBC-2. This
should solve the problem where the larger array systems are flushing
their non-volatile cache to disk when ZFS sends the cache flush;
though, of course, it assumes that vendors actually check this bit.
;-)
Dang, I must have missed this when I initially read the specs. Either
that, or I was looking at the original SBC document, which doesn't have
that bit.
We should probably change this immediately to behave as you suggest. My
only reservation would be if older devices puke on the command if that
bit is set.
Should I file a bug on this?
Yes, please.
Thanks for catching this.
--Bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
