On 07/20/2010 07:07 PM, Jeff Layton wrote: > On Tue, 20 Jul 2010 08:53:27 -0400 > Jeff Layton <jlayton@xxxxxxxxx> wrote: > >> On Mon, 5 Jul 2010 18:12:27 +0530 >> Suresh Jayaraman <sjayaraman@xxxxxxx> 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 <sjayaraman@xxxxxxx> >> >> 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)? >> In case of multisession mounts, there is a cache cookie per tcon, but they will point to the same cached inodes. > 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. yeah. I think the description could be a bit more clear.. Thanks, -- Suresh Jayaraman -- 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
