On 04/24/2013 02:20 PM, Black, David wrote:
Jeremy,
It looks like, you, Paolo and Ric have hit the nail on the head here - this is
a nice summary, IMHO:
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
If the device can promise this, we don't care (and don't know) how it
manages that promise. It can leave the data on battery backed DRAM, can
archive it to flash or any other scheme that works.
That's exactly the point of SYNC_NV=1.
Well its the point, but the specification is written such that the vendors can
choose to implement it any way they wish, especially for split cache
systems where there is both volatile and non volatile cache.
Independent of T10's best intentions at the time, the implementations aren't
doing what's needed or intended, and I'd guess that the SYNC_NV bit is not
being set to 1 by [other people's ;-) ] software that should be setting it
to 1 if it were paying attention to the standard.
This is further complicated by it being completely legitimate wrt the SCSI
standard to put non-volatile cache in a system and not have the SCSI interface
admit that the non-volatile cache exists (WCE=0, SYNCHRONIZE CACHE is a no-op
independent of the value of SYNC_NV).
I believe that Rob Elliot's 13-050 proposal to obsolete SYNC_NV and re-specify
SYNCHRONIZE CACHE to make all data non-volatile by whatever means the target
chooses is what T10 should do, and that matches Ric's summary:
If the device can promise this, we don't care (and don't know) how it
manages that promise. It can leave the data on battery backed DRAM, can
archive it to flash or any other scheme that works.
Beyond that, attempting to manage drive removal from storage systems via the
SCSI interface with standard commands is a waste of time and effort, IMHO.
In a serious storage array (and even some fairly simple RAID controllers), some
vendor-specific "magic" is needed to get the array (or controller) to prepare
so that the drive can be removed cleanly. To oversimplify, it's not enough to
flush data to the drive; the array or controller is stateful, and hence has
to be told to "forget" the drive, where "forget" involves things that are
rather implementation-specific.
Thanks,
--David
So I think that leaves us with some arrays that might benefit from Paolo's
proposed patch, but almost certainly still will need to be able to "ignore
flushes" for some block device accessing DB's, etc....
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
