On Mon, Oct 30, 2023 at 12:16 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Thu, 19 Oct 2023 at 16:33, Amir Goldstein <amir73il@xxxxxxxxx> 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).
>
These tests do not do msync.
Specifically, test generic/080 encodes an expectation that
c/mtime will be changed for mmaped write following mmaped read.
Not sure where this expectation is coming from?
Author: Omer Zilberberg <omzg@xxxxxxxxxxxxx>
Date: Wed Apr 1 15:39:36 2015 +1100
generic: test that mmap-write updates c/mtime
When using mmap() for file i/o, writing to the file should update
it's c/mtime. Specifically if we first mmap-read from a page, then
memap-write to the same page.
This test was failing for the initial submission of DAX because
pfn based mapping do not have an page_mkwrite called for them.
The new Kernel patches that introduce pfn_mkwrite fixes this test.
Test adapted from a script originally written by Dave Chinner.
> 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.
Makes sense.
I was thinking about a cache coherency model for FUSE passthough:
At any given point, if we have access to a backing file, we can compare
the backing file's inode timestamps with those of the FUSE inode.
If the timestamps differ, we do not copy them over to FUSE inode,
as overlayfs does, but we invalidate the FUSE attribute cache.
We can perform this checkup on open() release() flush() fsync()
and at other points, such as munmap() instead of unconditionally
invalidating attribute cache.
I already used tha model for atime update:
/* Mimic atime update policy of backing inode, not the actual value */
if (!timespec64_equal(&backing_inode->i_atime, &inode->i_atime))
fuse_invalidate_atime(inode);
Do you think that can work?
Do you think that the server should be able to configure this behavior
or we can do it by default?
Thanks,
Amir.
