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). -- 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
