[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <672d300566c69_10bb7294d7@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 7 Nov 2024 13:24:21 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Asahi Lina <lina@...hilina.net>, Jan Kara <jack@...e.cz>, Dan Williams
<dan.j.williams@...el.com>
CC: Dave Chinner <david@...morbit.com>, Matthew Wilcox <willy@...radead.org>,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner
<brauner@...nel.org>, Sergio Lopez Pascual <slp@...hat.com>,
<linux-fsdevel@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>, <asahi@...ts.linux.dev>
Subject: Re: [PATCH] dax: Allow block size > PAGE_SIZE
Asahi Lina wrote:
[..]
> I don't think that's how it actually works, at least on arm64.
> arch_wb_cache_pmem() calls dcache_clean_pop() which is either dc cvap or
> dc cvac. Those are trapped by HCR_EL2<TPC>, and that is never set by KVM.
>
> There was some discussion of this here:
> https://lore.kernel.org/all/20190702055937.3ffpwph7anvohmxu@US-160370MP2.local/
>
> But I'm not sure that all really made sense then.
>
> msync() and fsync() should already provide persistence. Those end up
> calling vfs_fsync_range(), which becomes a FUSE fsync(), which fsyncs
> (or fdatasyncs) the whole file. What I'm not so sure is whether there
> are any other codepaths that also need to provide those guarantees which
> *don't* end up calling fsync on the VFS. For example, the manpages kind
> of imply munmap() syncs, though as far as I can tell that's not actually
> the case. If there are missing sync paths, then I think those might just
> be broken right now...
IIRC, from the pmem persistence dicussions, if userspace fails to call
*sync then there is no obligation to flush on munmap() or close(). Some
filesystems layer on those guarantees, but the behavior is
implementation specific.
Powered by blists - more mailing lists