> >> In case a platform doesn't provide explicit flush-hints but provides an > >> explicit flush callback, then nvdimm_has_flush() still returns '0' > >> indicating that writes do not require flushing. This happens on PPC64 > >> with patch at [1] applied, where 'deep_flush' of a region was denied > >> even though an explicit flush function was provided. > >> > >> Similar problem is also seen with virtio-pmem where the 'deep_flush' > >> sysfs attribute is not visible as in absence of any registered nvdimm, > >> 'nd_region->ndr_mappings == 0'. > > > > In case of async flush callback, do we still need "deep_flush" ? > > 'deep_flush' in libnvdimm (specifically 'deep_flush_store()') > anyways resorts to calling 'async_flush' callback if its defined. Which > makes sense to me since in absence of eADR, 'echo 1 > deep_flush' would > ensure that writes to pmem are now durable even if there is a sudden > power loss before cpu caches are flushed. > > On non-nfit architectures the 'async_flush' callback should provide such > a guarantee, which can be triggered by user-space writing to the > 'deep_flush' sysfs attr. > > In absence of 'deep_flush' sysfs attr not sure how else can user-space > forcibly trigger async_flush callback for dev-dax char devices. O.k. that means for filesystem DAX deep_flush is alternative to fsync/msync call. I still have to dig deeper to understand more about "QUEUE_FLAG_FUA" flag & why I was seeing REQ_FUA with virtio-pmem when doing fsync if its not enabled in function "blk_queue_write_cache". But this is for my understanding. Overall patch looks good to me and it looks to solve (not tested though) the warning for virtio-pmem as well. Reviewed-by: Pankaj Gupta <pankaj.gupta@xxxxxxxxx> Thanks, Pankaj
