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
Wow. Thanks! I’ll take a closer look once I can.
> 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.
Yes, I’ve noticed this, too. I just didn’t care to fix it here, because
it’s a pre-existing issue (I believe), and it isn’t related to the
submount-automount implementation – it’s just a bug in virtiofsd, basically.
> 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.
Will do.
> If there are no major issues, this should be
> good to go for v5.10.
Great :)
Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
