Re: T10 WCE interpretation in Linux & device level access

[Jeremy Linton <jlinton@tributary.com>]

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.

	Flushing the NV cache to medium (as is the current behavior) may not be a bad
idea anyway.

	Thats because I know of a large vendors array where the non-volatile cache
might be better described as the "sometimes" non-volatile cache. That is because
a failure to flush the volatile portions results in the non-volatile portions
being considered invalid when power is restored. This fences the volume, and the
usual method for recovering the array is to call support and have them
invalidate the NV portions of the cache. Thereby negating the whole reason for
having a NV cache. I'm sure they don't tell customers this fact when they sell
the array, when it happened in our lab I was in a state of shock for about a week.