On Tue, Aug 19, 2025 at 05:01:15PM +0200, Miklos Szeredi wrote:
> On Mon, 18 Aug 2025 at 22:01, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> > In theory only specialty programs are going to be interested in directio
> > or atomic writes, and only userspace nfs servers and backup programs are
> > going to care about subvolumes, so I don't know if it's really worth the
> > trouble to cache all that.
> >
> > The dio/atomic fields are 7x u32, and the subvol id is u64. That's 40
> > bytes per inode, which is kind of a lot.
>
> Agreed. This should also depend on the sync mode.
>
> AT_STATX_DONT_SYNC: anything not cached should be cleared from the mask.
>
> AT_STATX_FORCE_SYNC: cached values should be ignored and FUSE_STATX
> request sent.
IMO, if the caller asks for the weird statx attributes
(dioalign/subvol/write_atomic) then they probably prefer to wait to get
the attributes they asked for. I'd be willing to strip them out of the
request_mask if they affirm _DONT_SYNC though.
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());
> AT_STATX_SYNC_AS_STAT: ???
I have no idea what that means. :)
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.
I was just gonna ignore it.
[1] https://lore.kernel.org/linux-fsdevel/147948603812.5122.5116851833739815967.stgit@xxxxxxxxxxxxxxxxxxxxxx/
--D
> Thanks,
> Miklos
>
