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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.