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. Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
