On Tue, Aug 17, 2010 at 11:29 AM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > You cannot be more precise than the backing file system: this causes > non monotonity when the inodes are flushed (has happened in the past) True. But non-toy filesystems designed post-1990 support nanosecond timestamps. One-second resolution is a disaster for NFS servers and always has been. I wonder how many man-hours have been wasted dealing with the problem... I personally have seen it dozens of times in my career, but "use XFS" was always a solution. Until now, that is, when 300usec round trip network times, 3GHz processors, and "weak cache consistency" optimizations have conspired to bring it back, thanks to 4msec resolution timestamps. Even aside from any NFS issues, I myself would prefer accurate timestamps over a 10% boost for tight loops calling "utimes()" or whatever. But maybe that is just me. Anyway, to repeat my revised proposal: 1) Add a "sb_current_fs_time" member to "struct super_block". Make it a pointer to a function returning "struct timespec". Have it default to the current low-resolution implementation. 2) Modify the function "current_fs_time(struct super_block sb *)" to just "return sb->sb_current_fs_time(sb)". Might as well inline it too. 3) Add a mount option to allow the selection of the high-res time source; i.e., to set sb_current_fs_time to point to the high-res implementation. Would patches implementing this stand a realistic chance of being accepted? - Pat -- 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
