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. -- 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
