Thread (39 messages) 39 messages, 6 authors, 2015-11-20

Re: [PATCH v2 03/11] pmem: enable REQ_FUA/REQ_FLUSH handling

From: Andreas Dilger <hidden>
Date: 2015-11-14 00:43:28
Also in: linux-fsdevel, linux-mm, linux-xfs, lkml, nvdimm

On Nov 13, 2015, at 5:20 PM, Dan Williams [off-list ref] wrote:
On Fri, Nov 13, 2015 at 4:06 PM, Ross Zwisler
[off-list ref] wrote:
quoted
Currently the PMEM driver doesn't accept REQ_FLUSH or REQ_FUA bios.  These
are sent down via blkdev_issue_flush() in response to a fsync() or msync()
and are used by filesystems to order their metadata, among other things.

When we get an msync() or fsync() it is the responsibility of the DAX code
to flush all dirty pages to media.  The PMEM driver then just has issue a
wmb_pmem() in response to the REQ_FLUSH to ensure that before we return all
the flushed data has been durably stored on the media.

Signed-off-by: Ross Zwisler <redacted>
Hmm, I'm not seeing why we need this patch.  If the actual flushing of
the cache is done by the core why does the driver need support
REQ_FLUSH?  Especially since it's just a couple instructions.  REQ_FUA
only makes sense if individual writes can bypass the "drive" cache,
but no I/O submitted to the driver proper is ever cached we always
flush it through to media.
If the upper level filesystem gets an error when submitting a flush
request, then it assumes the underlying hardware is broken and cannot
be as aggressive in IO submission, but instead has to wait for in-flight
IO to complete.  Since FUA/FLUSH is basically a no-op for pmem devices,
it doesn't make sense _not_ to support this functionality.

Cheers, Andreas




Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help