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

[Miklos Szeredi <miklos@szeredi.hu>]

On Tue, 31 Oct 2023 at 11:28, Amir Goldstein <amir73il@gmail.com> wrote:

> 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?

Probably because "update on first store" is the de-facto standard on
linux (filemap_page_mkwrite -> file_update_time).

Thinking about it, the POSIX text is a bit sloppy, I think this is
what it wanted 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 the _first_ write reference to
the mapped region _since_the_last_msync()_ call and the next call to msync()
..."

Otherwise the linux behavior would be non-conforming.

> 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.

Yes, that makes sense as long as there's a 1:1 mapping between backing
files and backed files.

It's not the case for e.g. a blockdev backed fs.   But current
patchset doesn't support that mode yet, so I don't think we need to
care now.

> 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.

This check can be done directly in  fuse_update_get_attr(), no?

> 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?

I think this can be the default, and as we generalize the passthrough
behavior we'll add the necessary controls.

Thanks,
Miklos


>
> Thanks,
> Amir.