Re: [PATCH v14 00/12] FUSE passthrough for file io

From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Daniel Rosenberg <drosen@google.com>,
	 Paul Lawrence <paullawrence@google.com>,
	Alessio Balsini <balsini@android.com>,
	 Christian Brauner <brauner@kernel.org>,
	fuse-devel@lists.sourceforge.net,  linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v14 00/12] FUSE passthrough for file io
Date: Mon, 30 Oct 2023 11:16:46 +0100	[thread overview]
Message-ID: <CAJfpegtZGC93-ydnFEt1Gzk+Yy5peJ-osuZD8GRYV4c+WPu0EQ@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxh=cLySge6htd+DnJrqAKF=C_oJYfVrbpvQGik0wR-+iw@mail.gmail.com>

On Thu, 19 Oct 2023 at 16:33, Amir Goldstein <amir73il@gmail.com> wrote:

> generic/120 tests -o noatime and fails because atime is
> updated (on the backing file).
> This is a general FUSE issue and passthrough_hp --nocache fails
> the same test (i.e. it only passed because of attribute cache).
>
> generic/080, generic/215 both test for c/mtime updates after mapped writes.
> It is not surprising that backing file passthrough fails these tests -
> there is no "passthrough getattr" like overlayfs and there is no opportunity
> to invalidate the FUSE inode attribute cache.

This is what POSIX has to say:

"The last data modification and last file status change timestamps of
a file that is mapped with MAP_SHARED and PROT_WRITE shall be marked
for update at some point in the interval between a write reference to
the mapped region and the next call to msync() with MS_ASYNC or
MS_SYNC for that portion of the file by any process. If there is no
such call and if the underlying file is modified as a result of a
write reference, then these timestamps shall be marked for update at
some time after the write reference."

Not sure if the test is doing msync(), but invalidating cached c/mtime
on msync() shouldn't be too hard (msync -> fsync).

While the standard doesn't seem to require updating c/mtime on
mumap(2) if there was a modification, that might also make sense in
practice.

Thanks,
Miklos