Re: [RFC] nanoseconds vs. the epoch
Alexandre Ratchov <[email protected]>
| Newsgroups | gmane.comp.file-systems.ext2.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, May 31, 2006 at 02:49:58PM -0600, Andreas Dilger wrote: > A preliminary patch for nanosecond timestamps is underway. I consider it > useful to take (at least) the top two bits of the ns timestamp as an extension > to the seconds field, extending the unix epoch on 64-bit systems by (at least) > 272 years without needing more than a 64-bit timestamp. > > The unanswered question is whether we want to extend the epoch by some orders > of magnitude at the expense of resolution in the nanoseconds field? For > example, NTFS has 100ns resolution for files and if we bumped the ext3 > granularity to only 8ns we would gain 2176 years in the epoch department. > > The other alternative is to be "happy enough" with the 272-year extension > for the current 128-byte inodes, keeping 1ns maximum resolution and then > worry about this when we have a 64-bit inode and allocate a larger field > for seconds (48 bits is enough for 12M years...). > hi, it seems to me reasonable; just to be sure, you suggest to add 32bit fields that extend timestamps; 1s = 10^9ns, this fits in 30bits: - 30bit to extend the resolution to 1ns. - 2bit to extend the number to seconds since the epoch to 2^34, which corresponds 544 years. That leads to 1970 + 544 = 2514 In this way older systems that just ignore the time stamp extension will truncate the nanoseconds part, and will miss the two MSB of the seconds part. This will work until around 2106... am i mistaken? -- Alexandre