cifs: define inode-level cache object and register them
in [Kernel]
|
Prev: cifs: define superblock-level cache index objects and register them
Next: ipmi: fix module param sparse warnings
From: Suresh Jayaraman on 25 Jun 2010 09:00 On 06/23/2010 10:32 PM, David Howells wrote: > Suresh Jayaraman <sjayaraman(a)suse.de> wrote: > >> Define inode-level data storage objects (managed by cifsInodeInfo structs). >> Each inode-level object is created in a super-block level object and is >> itself a data storage object in to which pages from the inode are stored. >> >> The inode object is keyed by UniqueId. The coherency data being used is >> LastWriteTime and the file size. > > Isn't there a file creation time too? I think the creation time is currently being ignored as we won't be able to accomodate in POSIX stat struct. > I take it you don't support caching on files that are open for writing at this > time? > Yes. -- 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: Jeff Layton on 25 Jun 2010 13:00 On Fri, 25 Jun 2010 13:55:49 +0100 David Howells <dhowells(a)redhat.com> wrote: > Suresh Jayaraman <sjayaraman(a)suse.de> wrote: > > > I think the creation time is currently being ignored as we won't be able > > to accomodate in POSIX stat struct. > > The FS-Cache interface doesn't use the POSIX stat struct, but it could be > really useful to save it and use it for cache coherency inside the kernel. > > Out of interest, what does Samba do when it comes to generating a creation time > for UNIX where one does not exist? > (cc'ing samba-technical since we're talking about the create time) Looks like it mostly uses the ctime. IMO, the mtime would be a better choice since it changes less frequently, but I don't guess that it matters very much. I have a few patches that make the cifs_iget code do more stringent checks. One of those makes it use the create time like an i_generation field to guard against matching inodes that have the same number but that have undergone a delete/create cycle. They need a bit more testing but I'm planning to post them in time for 2.6.36. Because of how samba generates this number, it could be somewhat problematic to do this. What may save us though is that Linux<->Samba mostly uses unix extensions unless someone has specifically disabled them on either end. The unix extension calls don't generally send any sort of create time field, so we can't rely on it in those codepaths anyway. -- Jeff Layton <jlayton(a)samba.org> -- 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: Jeff Layton on 25 Jun 2010 18:30 On Fri, 25 Jun 2010 22:46:38 +0100 David Howells <dhowells(a)redhat.com> wrote: > Jeff Layton <jlayton(a)samba.org> wrote: > > > Looks like it mostly uses the ctime. IMO, the mtime would be a better > > choice since it changes less frequently, but I don't guess that it > > matters very much. > > I'd've thought mtime changes more frequently since that's altered when data is > written. ctime is changed when attributes are changed. > IIUC, updating mtime for a write is also an attribute change, and that affects ctime. According to the stat(2) manpage: The field st_ctime is changed by writing or by setting inode informa- tion (i.e., owner, group, link count, mode, etc.). > Note that Ext4 appears to have a file creation time field in its inode > (struct ext4_inode::i_crtime[_extra]). Can Samba be made to use that? > Is it exposed to userspace in any (standard) way? It would be handy to have that. While we're wishing...it might also be nice to have a standard way to get at the i_generation from userspace too. -- Jeff Layton <jlayton(a)samba.org> -- 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: Christoph Hellwig on 27 Jun 2010 14:30
On Sun, Jun 27, 2010 at 11:47:21PM +0530, Aneesh Kumar K. V wrote: > NFS ganesha pNFS also had a requirement for getting i_generation and > inode number in userspace. So may be we should now look at updating > stat or add a variant syscall that include i_generation and create time > in the return value What's missing in knfsd that you feel the sudden urge to move backwards to a userspace nfsd (one with a horribly crappy codebase, too). -- 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/ |