On Thu, 29 Jul 2010 09:04:01 +1000 Neil Brown <neilb@xxxxxxx> wrote: > On Wed, 28 Jul 2010 18:28:02 +0100 > David Howells <dhowells@xxxxxxxxxx> wrote: > > > Neil Brown <neilb@xxxxxxx> wrote: > > > > > ctime and mtime have real cache-coherence semantics which require them being > > > updated by the kernel (whether the cache is on an NFS client, in a backup > > > archive, or in a .o translation of a .c file). > > > > So does creation time, at least for CIFS caching. Creation time has potential > > for spotting when the object at a pathname has changed for something else, > > given the lack of inode number and inode generation from windows servers. > > Creation time gives us one more datum to use. > > This justifies for me why a CIFS client would want to extract the > creation-time from the CIFS protocol, but not why you want to expose it via a > generic interface. > The kernel/filesystem doesn't need to maintain creation-time to meet this > need, only the CIFS server needs to maintain it - the kernel/filesystem just > needs to provide somewhere to store it - xattrs. > > Given that we have an extensible attribute framework, it seems wrong to be > adding new attributes to *stat. If a given filesystem wants to store certain > attributes more efficiently, then it is welcome to intercept xattr calls and > store (say) "cifs.birthtime" directly at a known offset in the inode. > The problem with the above approach is that you're assuming that the data in question is always accessed via the CIFS server. If someone comes along and messes with the data outside of CIFS, then samba won't have knowledge of that and the birthtime will be wrong. There's some history behind this as well -- samba tracks windows ACLs via xattr and it can be very problematic keeping those up to date when the data is accessed outside of samba. I think presenting this data via xattr makes the most sense. It's simple and as Neil points out, it also provides us with a clealy settable interface. If we ever get an xstat-like syscall, we can always present the same data via that as well. I also think it's quite reasonable to consider tracking birthtime in a generic inode field. In the absence of that, filesystems could track this themselves in their filesystem-specific inode structs. Furthermore, I'll go ahead and propose the following (simple) semantics: 1) birthtime is initialized to the current time when a new inode is created 2) it's settable via the xattr to an arbitrary value Either way, the xattr for this ought to be named the same on all filesystems. Samba shouldn't need to know or care what the underlying filesystem is, as long as it presents the correct xattr. That should make samba happy, and be reasonably simple to implement. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
