On 07.05.20 13:24, Miklos Szeredi wrote: > On Thu, May 7, 2020 at 1:16 PM Max Reitz <[email protected]> wrote: >> >> On 07.05.20 11:56, Miklos Szeredi wrote: >>> On Wed, May 6, 2020 at 5:37 PM Max Reitz <[email protected]> wrote: >>>> >>>> From: Max Reitz <[email protected]> >> >> Oops. >> >>>> We want to allow submounts for the same fuse_conn, but with different >>>> superblocks so that each of the submounts has its own device ID. To do >>>> so, we need to split all mount-specific information off of fuse_conn >>>> into a new fuse_mount structure, so that multiple mounts can share a >>>> single fuse_conn. >>> >>> I have the following high level comments: >>> >>> Control filesystem: each fuse_mount gets a new entry, but they are all >>> aliases. I think we should just stick with just one entry for the >>> connection (and perhaps a symlink for each additional mount, but this >>> is of secondary importance). >> >> I have to admit that I didn’t spend much thought on any of this, but >> just went with what worked. Since one of the functions in control.c >> require the super block, I went with fuse_mount. >> >> I suppose for fuse_ctl_add_conn() (for @name), we can simply use the >> first fuse_mount’s device ID. > > Yes. > >> >>> BDI: we need to call set_bdi_congested/clear_bdi_congested for *all* >>> mounts of a connection. >> >> OK, then one entry per fuse_conn will work. >> >> But do we need to do the same in fuse_request_end() and >> fuse_request_queue_background()? > > Definitely. Otherwise one bdi could have its congestion state set, > and the other one cleared. Not good. > > Even better: share the bdi between submounts. This would make a lot > more sense and remove the need for loops.
Hm, isn’t bdi related to the (anonymous) block device “serving” the super block, and thus the st_dev value? (Which is necessarily different for all fuse_mounts) >>> Might make sense to look into getting rid of >>> bdi congestion handling completely, but this is not something I have a >>> good insight into right now. >>> >>> Notification: please create a fuse_ilookup() that takes fc and returns >>> (sb, inode) pair and call this instead ilookup5(). This way the loop >>> is moved to the place where it's actually necessary. >> >> Hm, sounds a bit cumbersome for the fuse_notify_* functions that don’t >> directly call ilookup5(). But they always have a callee that does, so I >> suppose I’ll just have to move that up to the caller. That should work >> then. > > I'd rather say: move the fc down to the callee. The kill_sb mutex can > remain in fuse_conn, so callers shouldn't need an sb. OK. Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
