2011/3/29 Pavel Shilovsky <piastryyy@xxxxxxxxx>: > 2011/3/28 Steve French <smfrench@xxxxxxxxx>: >> On Mon, Mar 28, 2011 at 1:50 PM, Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: >>> 2011/3/26 Jeff Layton <jlayton@xxxxxxxxxx>: >>>> On Sat, 26 Mar 2011 16:12:03 +0300 >>>> Pavel Shilovsky <piastryyy@xxxxxxxxx> 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@xxxxxxxxxx> >>>> >>> >>> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
