On Wed, Sep 03, 2025 at 11:55:25AM +0200, Miklos Szeredi wrote:
> On Tue, 2 Sept 2025 at 22:57, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> > You can, kind of -- either send the server FS_IOC_FSGETXATTR or
> > FS_IOC_GETFLAGS right after igetting an inode and set the VFS
> > immutable/append flags from that; or we could add a couple of flag bits
> > to fuse_attr::flags to avoid the extra upcall.
>
> How about a new FUSE_LOOKUPX that uses fuse_statx instead of fuse_attr
> to initialize the inode?
Or what if we enlarged fuse_attr? Its fields mostly duplicate what was
already in struct stat (and now struct statx):
struct fuse_attrx {
struct fuse_statx statx;
uint32_t flags; /* fuse_attr::flags */
};
Hrmm, fuse_attr is embedded in structs fuse_entry_out and
fuse_attr_out. FUSE_{LOOKUP,OPEN,CREATE,SETATTR,GETATTR} (and
direntplus) would need to be rototilled to support the new structure,
and either you need new command codes for all that, or I guess one could
set out_argvar = true and switch the out-struct decoding based on the
size returned.
That sounds like a project in and of itself.
> > The flag is very much needed for virtiofs/famfs (and any future
> > fuse+iomap+fsdax combination), because that's how application programs
> > are supposed to detect that they can use load/store to mmap file regions
> > without needing fsync/msync.
>
> Makes sense.
>
> > > I also fell that all unknown flags should also be masked off, but
> > > maybe that's too paranoid.
> >
> > That isn't a terrible idea.
>
> So in conclusion, the following can be passed through from the fuse
> server to the statx syscall (directly or cached):
>
> COMPRESSED
> NODUMP
> ENCRYPTED
> VERITY
> WRITE_ATOMIC
Right.
> The following should be set (cached) in the relevant inode flag:
>
> IMMUTABLE
> APPEND
Right, S_IMMUTABLE and S_APPEND.
> The following should be ignored and the VFS flag be used instead:
>
> AUTOMOUNT
> MOUNT_ROOT
> DAX
Yes to the first two.
As for /setting/ S_DAX, I think we just keep using FUSE_ATTR_DAX like we
do now, since that's baked into the kernel <-> libfuse interface and
can't go away. That would fit nicely with how the other filesystems do
it.
> And other attributes should just be ignored.
I prefer to say "Other attribute bits are undefined and should just be
ignored." :)
> Agree?
I think we do, except maybe the difficult first point. :)
--D
> Thanks,
> Miklos
>
