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.
James
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.
Regards,
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
