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. -- Thanks, Steve -- 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
