Implementation of SYNC_NV bit

Gerry Houlder gerry.houlder at
Mon Jul 19 14:21:27 PDT 2010

Formatted message: <a href="">HTML-formatted message</a>

My company has been reviewing the definition of the SYNC_NV bit in the
The current definition has the plain SYNCHRONIZE CACHE command forces all
volatile and non-volatile caches to be flushed to medium while the setting
of SYNC_NV bit only forces volatile caches to be flushed to medium. Thus, if
an implementation has several Gigabytes of non-volatile cache the plain
SYNCHRONIZE CACHE command could take minutes to complete but the (more
recently defined) SYNCHRONIZE CACHE with SYNC_NV=1 could complete much
faster if only a few Megabytes of volatile cache needed to be flushed to the
medium. Unfortunately, this seems backwards from the host expectations;
hosts expect the plain SYNCHRONIZE CACHE to be completed rather quickly and
might be more willing to accept a long (could be minutes) completion time in
a newer version of the command (like one that has the SYNC_NV bit set).
My purpose of sending this email is to gather opinions from host vendors to
see if:
(a) do you use the SYNCHRONIZE CACHE command with SYNC_NV bit set to 1;
(b) what expectation is ther for completion time of this command with and
without SYNC_NV bit set; and
(c) how would you feel about redefining the SYNC_NV bit to invert its
If the SYNC_NV bit were changed in meaning, I would propose to make the
plain SYNCHRONIZE CACHE command flush only volatile cache to medium and
SYNC_NV=1 would cause non-volatile caches as well as volatile caches be
flushed to medium.
Unless the responses to this email are overwelmingly negative, I plan to
introduce a proposal at the next T10 meeting that will change the meaning of
the SYNC_NV bit is this manner. I want to hear opinions, both for and
against, ahead of time so I have a sense of how this group will treat this

More information about the T10 mailing list