On Feb 13, 2008 09:07 -0500, Trond Myklebust wrote: > On Wed, 2008-02-13 at 13:52 +0100, Christoph Hellwig wrote: > > Btw, stupid question: the commit message for the i_version changes > > mentions this is to work around lack of granularity for ctime updates. > > But all modern filesystems (and I includ ext4 in that here) have 64bit > > timestamps already, so that should be enough. It would certainly > > avoid all this additional code, and especially the additional space > > used in struct inode which can hurt quite a lot. > > Support for 64-bit on-disk time stamps alone does not suffice. In order > to label all file/directory changes unambiguously, you would also need > nanosecond timekeeping support. > > An example is XFS, which has had on-disk support for 64-bit time stamps > since forever, but is in practice limited by the Linux default 250Hz > internal clock. We've seen plenty of examples of NFS clients missing > updates on the resulting filesystem due to the fact that they occurred > within 1/250 sec of each other.
The other issue which unfortunately makes ctime a non-starter is the ability of ctime to go backward due to clock changes. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
