Re: T10 WCE interpretation in Linux & device level access

[Ric Wheeler <ricwheeler@gmail.com>]

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