On Wed, Aug 20, 2025 at 11:16:42AM +0200, Miklos Szeredi wrote:
> On Wed, 20 Aug 2025 at 00:51, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> > Something like this, maybe?
> >
> > #define FUSE_UNCACHED_STATX_MASK (STATX_DIOALIGN | \
> > STATX_SUBVOL | \
> > STATX_WRITE_ATOMIC)
> >
> > and then in fuse_update_get_attr,
> >
> > if (!request_mask)
> > sync = false;
> > else if (request_mask & FUSE_UNCACHED_STATX_MASK) {
> > if (flags & AT_STATX_DONT_SYNC) {
> > request_mask &= ~FUSE_UNCACHED_STATX_MASK;
> > sync = false;
> > } else {
> > sync = true;
> > }
> > } else if (flags & AT_STATX_FORCE_SYNC)
> > sync = true;
> > else if (flags & AT_STATX_DONT_SYNC)
> > sync = false;
> > else if (request_mask & inval_mask & ~cache_mask)
> > sync = true;
> > else
> > sync = time_before64(fi->i_time, get_jiffies_64());
>
> Yes.
>
> > Way back in 2017, dhowells implied that it synchronises the attributes
> > with the backing store in the same way that network filesystems do[1].
> > But the question is, does fuse count as a network fs?
> >
> > I guess it does. But the discussion from 2016 also provided "this is
> > very filesystem specific" so I guess we can do whatever we want?? XFS
> > and ext4 ignore that value. The statx(2) manpage repeats that "whatever
> > stat does" language, but the stat(2) and stat(3) manpages don't say a
> > darned thing.
Ohhh, only now I noticed that it's one of those trickster flags symbols
like O_RDONLY that are #define'd to 0. That's why there's no
(flags & SYNC_AS_STAT) anywhere in the codebase.
> Actually we can't ignore it, since it's the default (i.e. if neither
> FORCE_SYNC nor DONT_SYNC is in effect, then that implies
> SYNC_AS_STAT).
>
> I guess the semantics you codified above make sense. In words:
>
> "If neither forcing nor forbidding sync, then statx shall always
> attempt to return attributes that are defined on that filesystem, but
> may return stale values."
Where is that written? I'd like to read the rest of it to clear my
head. :)
> As an optimization of the above, the filesystem clearing the
> request_mask for these uncached attributes means that that attribute
> is not supported by the filesystem and that *can* be cheaply cached
> (e.g. clearing fi->inval_mask).
Hrmm. I wouldn't want to set fi->inval_mask bits just because a
FUSE_STATX message ignored a mask bit one time -- imagine a filesystem
with tiered storage. A file might be on slow hdd storage which means no
fancy things like atomic writes, but later it might get promoted to
faster nvme which does support that.
Anyway I'll send out rfcv4 today, which has the above update_get_attr
logic in it.
--D
> Thanks,
> Miklos
