On Tue, 20 Jul 2010 08:53:27 -0400 Jeff Layton <[email protected]> wrote:
> On Mon, 5 Jul 2010 18:12:27 +0530 > Suresh Jayaraman <[email protected]> wrote: > > > Define superblock-level cache index objects (managed by cifsTconInfo > > structs). > > Each superblock object is created in a server-level index object and in > > itself > > an index into which inode-level objects are inserted. > > > > The superblock object is keyed by sharename. The UniqueId/IndexNumber is > > used to > > validate that the exported share is the same since we accessed it last time. > > > > Signed-off-by: Suresh Jayaraman <[email protected]> > > Hmm...Steve started merging these already but I've just now had the > chance to review them. > > This approach may be a problem. It seems to make the assumption that > there is only a single tcon per superblock. How exactly will this work > when there are multiple tcons per superblock as will be the case with > multisession mounts? > > By having a cache cookie per tcon, will that mean that you'll > potentially have multiple versions of cached inodes (one for each tcon)? > Ahh nm. This shouldn't be a problem since this key is based on the sharename only and that will be the same between the multiple tcons. Please disregard! -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
