On 10/17/2016 01:19 PM, James Bottomley wrote:
That's not what I get from the change log.  What it says to me is
> >that the caches are currently firmware managed.  Barring firmware
> >bugs, that means that we currently don't have any integrity issues.
>Your understanding (or the change log) is incorrect.
There's no current way in English of construing "as firmware takes care
of flushing cache" to mean its inverse, so the changelog needs updating
to explain that firmware does*not*  take care of cache flushing, so
effectively nothing does and we'll need a cc to stable if the problem
is that nothing takes care of flushing the drive caches.


I agree that the changelog should be fixed, but the code itself is clearly broken in how is discards synchronize_cache commands. I assume Sumit will update that for use.

The specific situation is this:

* when using devices in RAID mode, the firmware does handle cache flushes (I assume it disables the back end disk write caches and handles its HBA write cache as you would expect).

* when using devices in non-RAID mode or pass through mode where the backend disks have write cache enabled, dropping the "SYNCHRONIZE_CACHE" commands in the driver is *never* correct for any disk with a volatile write cache

* there is no standard way to distinguish devices that have WCE set and have non-volatile write caches, so we have to assume the worst.



To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to