[Virtio-fs] [RFC 3/5] fuse: Split fuse_mount off of fuse_conn

[Max Reitz]

On 07.05.20 13:24, Miklos Szeredi wrote:
> On Thu, May 7, 2020 at 1:16 PM Max Reitz <mreitz at redhat.com> wrote:
>>
>> On 07.05.20 11:56, Miklos Szeredi wrote:
>>> On Wed, May 6, 2020 at 5:37 PM Max Reitz <mreitz at redhat.com> wrote:
>>>>
>>>> From: Max Reitz <xanclic at xanclic.moe>
>>
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20200507/dc9884bf/attachment.sig>