[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-cifs
Subject:    Re: smb2 and shared superblock model
From:       Pavel Shilovsky <piastryyy () gmail ! com>
Date:       2011-03-29 6:49:35
Message-ID: AANLkTik1KuNLQYXn32ZzCC7jOyCXtMxF5dMHz903EFW9 () mail ! gmail ! com
[Download RAW message or body]

2011/3/29 Pavel Shilovsky <piastryyy@gmail.com>:
> 2011/3/28 Steve French <smfrench@gmail.com>:
>> On Mon, Mar 28, 2011 at 1:50 PM, Pavel Shilovsky <piastryyy@gmail.com> wrote:
>>> 2011/3/26 Jeff Layton <jlayton@redhat.com>:
>>>> On Sat, 26 Mar 2011 16:12:03 +0300
>>>> Pavel Shilovsky <piastryyy@gmail.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Today I investigated a bit about how to insert sharedblock model into
>>>>> cifs and get it work correctly with smb2.1 leases. Now we have the
>>>>> following archtecture:
>>>>> inode -> superblock -> tlink -> tcon -> sess -> srv - so we can
>>>>> definitely say what ses id and tree id we should use for a requested
>>>>> inode. It's from the one hand.
>>>>>
>>>>> From another hand, we should share cached data between several
>>>>> sessions from the same client (according to SMB2 spec we should have
>>>>> one global file table). And everything is good if we will share
>>>>> superblock between several mounts that uses the same sess id and tcon
>>>>> id. But if these are different sessions that's brings a problem. A
>>>>> superblock is linked to only one tcon id and sess id but we need to
>>>>> share it between completely different sessions. So, it seems to me
>>>>> that according to nowadays situation we can't share the same data
>>>>> between different sessions.
>>>>>
>>>>> So, now I suggest to share a superblock only between different mounts
>>>>> of the same sess id and tcon id. And every time we negotiate a
>>>>> different session (e.x. from another username) we should change
>>>>> ClientGUID. It causes the server to think that these are different
>>>>> clients and it won't grant leases on parallel opens from these
>>>>> sessions. So, in this case we solve data coherency problem but, of
>>>>> course, miss some advantages of SMB2 protocol.
>>>>>
>>>>> Your comments/thoughts?
>>>>>
>>>>
>>>> That's not quite correct...
>>>>
>>>> A superblock can point to more than one tcon in the multiuser mount
>>>> case. That's the whole reason for the tlink structure in the first
>>>> place.
>>>>
>>>> The reason for a shared superblock is that you intend to mount the
>>>> exact same data in multiple places and don't intend to bind mount. With
>>>> NFS for instance, consider the case where you do something like this:
>>>>
>>>>    # mount server:/export /mount1
>>>>    # mount server:/export/subdir /mount2
>>>>
>>>> Suppose then that you access these files:
>>>>
>>>>    /mount1/subdir/file1
>>>>    /mount2/file1
>>>>
>>>> Traditionally, that would give you two different inodes connected to
>>>> two different superblocks. Cache consistency can easily be off, you end
>>>> up with duplicate data in cache, and dealing with fscache is
>>>> problematic since you can end up with collisions in the cache.
>>>>
>>>> To fix that (mostly for the fscache problem), David Howells converted
>>>> NFS so that it would share superblocks in this situation. The two
>>>> vfsmounts point to the same superblock, but the root dentry is different
>>>> for each.
>>>>
>>>> So...what does this mean for CIFS? We already look for an existing
>>>> server, session and tcon when we mount. To do this for CIFS you would
>>>> simply need to go a step farther and look for an existing superblock
>>>> that matches your needs and deal with setting up the root dentry
>>>> correctly.
>>>>
>>>> I urge you to have a look at what NFS does in this case. It's
>>>> non-trivial but that is probably the best model for doing this in CIFS.
>>>>
>>>> Here's the catch though...you now have to deal with all of the CIFS
>>>> mount options and decide which settings mean that you need to create a
>>>> new superblock instead of using an existing one on a new mount.
>>>>
>>>> --
>>>> Jeff Layton <jlayton@redhat.com>
>>>>
>>>
>>> So, I suggest to do the following - before we get a superblock we
>>> should figure out what structures we can share:
>>> 1) try to share tcp_sesion;
>>> 2) if succeed - try to share smb_session;
>>> 3) if succeed - try to share tcon;
>>> 4) if succeed - share a sb which tcon points to.
>>>
>>> So, in this case there is no need to use sget call with 'compare' and
>>> 'set' callbacks like NFS does it, I think.
>>>
>>> As for multiuser mode - It won't bring complexity because in this case
>>> we don't touch its code.
>>
>> At a high level, your description above makes sense, but the
>> details can get tricky.  In practice some differences
>> in mount options etc. are not "disqualifying" when trying to
>> share a superblock or tcon but it we have to consider
>> the options one by one.
>>
>>
>
> I agree with this. I also want to say that every time when we can't
> share superblock we should change ClientGUID to let the server think
> that these are different clients and the server shouldn't grant RWH
> lease for both of them (because they have different caches due to
> different superblocks).
>

I looked at the spec ([MS-SMB2].pdf, page 125) and found out that we
should use different LeaseKey for the same files in these cases and
don't change ClientGUID. I think we can simply generate new LeaseKey
value for every inode in alloc_inode or, like the spec suggests, when
we open it first time in cifs_open/cifs_create.

-- 
Best regards,
Pavel Shilovsky.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]