On 11.09.20 13:07, Miklos Szeredi wrote: > On Fri, Sep 11, 2020 at 12:25 PM Stefan Hajnoczi <[email protected]> wrote: >> >> On Wed, Sep 09, 2020 at 08:45:56PM +0200, Max Reitz wrote: >>> This is a flag for fuse_attr.flags that indicates that the given entry >>> resides on a different filesystem than the parent, and as such should >>> have a different st_dev. >>> >>> Signed-off-by: Max Reitz <[email protected]> >>> --- >>> include/uapi/linux/fuse.h | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h >>> index de94c11cfc3b..c034cdf8f5f4 100644 >>> --- a/include/uapi/linux/fuse.h >>> +++ b/include/uapi/linux/fuse.h >>> @@ -417,6 +417,13 @@ struct fuse_file_lock { >>> */ >>> #define FUSE_FSYNC_FDATASYNC (1 << 0) >>> >>> +/** >>> + * fuse_attr flags >>> + * >>> + * FUSE_ATTR_SUBMOUNT: File/directory is a submount point >>> + */ >>> +#define FUSE_ATTR_SUBMOUNT (1 << 0) >> >> If you respin, please add a little more detail here. How should clients > > I'm just reviewing/queuing this, so no need to respin. > >> act when this flag is detected (which FUSE messages should they send to >> deal with submounts)? > > Actually, no new messages, since the reply containing > FUSE_ATTR_SUBMOUNT already refers to the submount root. I'll fix the > description.
Perhaps it’s still useful to note how this flag is supposed to be handled; i.e. that it’s a hint to the kernel to create an auto-mounted submount. > And since there's no separate information for the actual mount point > (userspace can't obtain it) AT_NO_AUTOMOUNT users become confused due > to the dummy mountpoint becoming visible with all the wrong data. > Maybe the fix is to force automount even with AT_NO_AUTOMOUNT. Will > look into that. If that’s possible... Though Dave did mention that it seems intentional that auto-mounts aren’t mounted on stat, so as not to overwhelm the system on a plain ls call. Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
