On Wed, Sep 23, 2020 at 5:45 PM Max Reitz <[email protected]> wrote: > > On 18.09.20 17:25, Miklos Szeredi wrote: > > Pushed an updated version to fuse.git#submounts. > > > > Also attached incremental patch (against rebase of > > virtiofs-submounts-v2 on fuse.git#for-next). > > > > Changes: > > > > 1) rebased on top of DAX patches > > 2) fixed CUSE > > 3) added locking for fc->mounts list > > 4) dissociate lifetime of fc from lifetime of root mount > > 5) do not hash mountpoint inodes > > 6) add FUSE_SUBMOUNTS init flag (replaces FUSE_ATTR_FLAGS but > > slightly different usage) > > 7) various cleanups > > > > Note, the effect of 5 can only be observed if the same directory is > > bind mounted into multiple places: > > > > HOST: > > cd /mnt > > mkdir 1 2 > > mount --bind /dev/shm 1 > > mount --bind /dev/shm 2 > > > > GUEST: > > mount -t virtiofs mnt /mnt > > cd /mnt/1 > > ls ../2 > > /bin/pwd > > > > If the mountpoint is hashed, then the "ls ../2" will basically result > > in /mnt/1 inode being moved to /mnt/2, which is not what we want. I > > don't think there's any negative side effect of the mountpoint being > > unhashed, but this is a bit subtle. > > > > > > On the server side, keying on just st_ino/st_dev is a really crude way > > of mapping out mounts. Take this example: > > > > HOST: > > cd /mnt > > mkdir 1 > > mount --bind /dev/shm 1 > > cd 1 > > mkdir 2 > > mount --bind /mnt 2 > > ls /mnt/1/2/1 > > > > GUEST: > > mount -t virtiofs mnt /mnt > > ls /mnt/1/2/1 > > 2 > > ls /mnt/1/2/1/2/1/2/1/ > > 2 > > > > So what we really need is keying on mount ID as well. > > > > Attaching an incremental patch to do that. Needs v5.8 kernel on host > > to actually make a difference, but commit fa2fcf4f1df1 ("statx: add > > mount ID") is trivial to backport to any kernel that has statx. > > > > Please review and test. If there are no major issues, this should be > > good to go for v5.10. > > As for the virtiofsd patch, I wonder about: > > > #if 0 && defined(HAVE_STATX) && STATX_MNT_ID > > Shouldn’t the 0 not be there? And should STATX_MNT_ID be wrapped in > defined()?
Right, that was left there from testing. > Furthermore I wonder why you have removed the parent_dev logic. With > your patch, FUSE_ATTR_SUBMOUNT can be announced only by those functions > that invoke lo_do_lookup(). Is it OK to do so only there, and not every > time a fuse_attr is returned (be it as part of fuse_entry_out, as by > lo_link(), or directly by lo_getattr())? No, object creation never results in a mounted object. If the newly created object is mounted on at a later time, the revalidate logic will take care of that. > (Also, the virtiofsd series will need a bit of an update with > FUSE_SUBMOUNTS replacing FUSE_ATTR_FLAGS.) > Yes, Thanks, Miklos _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
