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.
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."
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).
Thanks,
Miklos
