On Wed, Apr 04, 2018 at 05:03:07PM -0700, Dan Williams wrote:
> "Currently, fsdax applications can assume that if they call fsync or
> msync on a dax mapped file that any pending writes that have been
> flushed out of the cpu cache will be also be flushed to the lowest
> possible persistence / failure domain available on the platform. In
> typical scenarios the platform ADR capability handles marshaling
> writes that have reached global visibility to persistence. In
> exceptional cases where ADR fails to complete its operation software
> can detect that scenario the the "last shutdown" health status check
> and otherwise mitigate the effects of an ADR failure by protecting
> metadata with the WPQ flush. In other words, enabling device-dax to
> optionally trigger WPQ Flush on msync() allows applications to have
> common implementation for persistence domain handling across fs-dax
> and device-dax."
This sounds totally bogus. Either ADR is reliable and we can rely on
it all the time (like we assume for say capacitors on ssds with non-
volatile write caches), or we can't rely on it and the write through
store model is a blatant lie. In other words - msync/fsync is what
we use for normal persistence, not for working around broken hardware.
In many ways this sounds like a plot to make normal programming models
not listening to the pmem.io hype look bad in benchmarks..
Linux-nvdimm mailing list