On Sunday 16 January 2005 05:37, Andi Kleen wrote: > Andreas Gruenbacher <[EMAIL PROTECTED]> writes: > > this is a spin-off of an old patch by Alex Tomas <[EMAIL PROTECTED]>: > > Alex originally had nanosecond timestamps in his original patch; here is > > a rejuvenated version. Please tell me what you think. Alex also added a > > create timestamp in his original patch. Do we actually need that? > > > > Nanoseconds consume 30 bits in the 32-bit fields. The remaining two bits > > currently are zeroed out implicitly. We could later use them remaining > > two bits for years beyond 2038. > > Looks good. Just two suggestions: > > - Provide an mount option to turn it off because there may be > performance regressions in some workload because inodes will be > flushed more often. > [I actually considered doing this generally at the VFS level > when doing the s_time_gran patch, but it needed some more changes > that I didn't want to do at that time. Doing it in the FS as > interim solution would be fine too]
I think I agree, also with doing it at the VFS layer. We must make sure that eventually the most recent timestamp makes it to disk (unless the machine crashes, in which case slightly out-of-date timestamps probably can be tolerated). > - Use the 2 bits for additionals years right now on 64bit > hosts. No need to keep the y2038 issue around longer than necessary. Yes. Actually zeroing out the upper two bits is wrong for timestamps before the epoch if we use plain two's complement representation. The two bits give us an extended range of about [1697 .. 2242] instead of [1901 .. 2038]. -- Andreas Gruenbacher <[EMAIL PROTECTED]> SUSE Labs, SUSE LINUX PRODUCTS GMBH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
