On Mon, Jun 20, 2022 at 09:40:11AM +1000, Dave Chinner wrote: > That doesn't change the fact we are issuing cache flushes from the > log checkpoint code - it just changes how we issue them. We removed > the explicit blkdev_issue_flush_async() call from the cache path and > went back to the old way of doing things (attaching it directly to > the first IO of a journal checkpoint) when it became clear the async > flush was causing performance regressions on storage with really > slow cache flush semantics by causing too many extra cache flushes > to be issued. Yes. Also actualy nvidmms (unlike virtio-pmem) never supported async flush anyway and still did the cache flush operations synchronously anyway. > To me, this smells of a pmem block device cache flush issue, not a > filesystem problem... Yes. Especially as normal nvdims are designed to not have a volatile write cache in the storage device sense anyway - Linux just does some extra magic for REQ_PREFLUSH commands that isn't nessecary and gives all thus funky userspace solution or snake oil acadmic file systems extra advantages by skipping that..
