cifs: define superblock-level cache index objects and register them
in [Kernel]
|
Prev: Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV guests.
Next: cifs: register CIFS for caching
From: David Howells on 23 Jun 2010 13:00 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 validate the root directory of the share in some way? David -- 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: David Howells on 25 Jun 2010 09:00 Suresh Jayaraman <sjayaraman(a)suse.de> wrote: > 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. You could convert the UNC name to an IP address, and just use that as your key. > > 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. David -- 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: David Howells on 25 Jun 2010 09:30 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 coherent or not from the above, you can always use LastWriteTime, ChangeTime and EndOfFile and just discard the whole subtree if they differ. David -- 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: David Howells on 28 Jun 2010 09:30
Suresh Jayaraman <sjayaraman(a)suse.de> wrote: > Did you mean we need to validate differently for different servers? You may need to, yes, as different servers may make different attributes available. This isn't too bad. Each server index record in the cache has freeform auxiliary data, just as does each file data record. You could, say, stick a byte at the front that indicates what you've stored in there. David -- 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/ |