cifs: define superblock-level cache index objects and register them
in [Kernel]
|
Prev: [PATCH] Staging: comedi: Coding style cleanups in adv_pci_dio.c
Next: cifs: define inode-level cache object and register them
From: Suresh Jayaraman on 25 Jun 2010 08:50 On 06/23/2010 10:28 PM, David Howells wrote: > Suresh Jayaraman <sjayaraman(a)suse.de> 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. >> >> Currently, the superblock objects are keyed by sharename. > > Seems reasonable. Is there any way you can check that the share you are > looking at on a server is the same as the last time you looked? Can you Good point. I thought of using TID (Tree identifier; a unique ID for a resource in use by client) along with sharename. But, Server is free to reuse them when the tree connection closes and does not guarantee the same Tid for a particular resource across tree connections. Also, considering the UNC name of the resource (//server/share) may not be a good idea too as the cache will not be used when for e.g. IPaddress is used to mount. So, if a server does something like this: - export a share 'foo' (original server path: /export/vol1/foo) - client mounts and uses it - server unexports the share 'foo' - server exports 'foo' (original sever path: /export/vol2/foo) we have a bit of problem.. > validate the root directory of the share in some way? > I don't know if there is a way to do this. Thanks, -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Suresh Jayaraman on 28 Jun 2010 09:00
On 06/25/2010 06:56 PM, David Howells wrote: > David Howells <dhowells(a)redhat.com> wrote: > >>>> validate the root directory of the share in some way? >>> >>> I don't know if there is a way to do this. >> >> Is there an inode number or something? Even the creation time might do. > > Looking in cifspdu.h, there are a number of things that it might be possible > to use. > > (1) FILE_ALL_INFO: CreationTime, IndexNumber, IndexNumber1, FileName > (assuming this isn't flattened to '\' or something for the root of a > share. > > (2) FILE_UNIX_BASIC_INFO: DevMajor, DevMinor, UniqueId. > > (3) FILE_INFO_STANDARD: CreationDate, CreationTime. > > (4) FILE_INFO_BASIC: CreationTime. > > (5) FILE_DIRECTORY_INFO: FileIndex, CreationTime, FileName. > > (6) SEARCH_ID_FULL_DIR_INFO: FileIndex, CreationTime, UniqueId, FileName. > > (7) FILE_BOTH_DIRECTORY_INFO: FileIndex, CreationTime, ShortName, FileName. > > (8) OPEN_RSP_EXT: Fid, CreationTime, VolumeGUID, FileId. > > You may have to choose different sets of things, depending on what the server > has on offer. Also, don't forget, if you can't work out whether a share is Did you mean we need to validate differently for different servers? I just did some testing and it looks like we could rely on CreationTime, IndexNumber for validating with Windows servers (FileName is relative to the mapped drive) and UniqueId for validating with Samba servers. I did not test all possibilities (there could be more). > coherent or not from the above, you can always use LastWriteTime, ChangeTime > and EndOfFile and just discard the whole subtree if they differ. > Thanks, -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |