Re: [RFC] nanoseconds vs. the epoch

Hi,

On Wed, 2006-05-31 at 14:49 -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 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...).

I don't follow --- the proposed ns+epoch extension is going to require
an extra 16 bytes, so surely this is all work that *cannot* fit in
existing 128-byte inodes?

I think one of the major questions is whether we want to do anything to
extend epoch for existing, 128-byte inodes.  If we are happy with
requiring a reformat for post-2038 dates, then we've got a lot of
freedom to use more inode fields; but if we want to offer *just* epoch
extension, with no sub-second timestamp granularity, for existing
filesystems, then we need to store that extension somewhere other than
the new ns fields.

We don't need a whole lot of space for this, either; even just 8 bits
would give us 2 new bits per timestamp, giving us that same 272-year
extension.

You could equally argue that by any time even close to 2038, computers
will be so fast that second-granularity timestamps are going to be
almost useless.  They are already a hindrance in many cases.

--Stephen