Re: [RFC] nanoseconds vs. the epoch

On Jun 02, 2006  17:56 +0100, Stephen C. Tweedie wrote:
> 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 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?

Sorry for confusion, the 48-bit proposal is for the future "64-bit inode"
format (likely at least 256 bytes in size).

> 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.

Well, we aren't going to use those 2 bits for anything else, so we may
as well extend the epoch usefully.  I have a patch already for this,
only missing being able to "support" the RO_COMPAT_NSEC flag, which we
haven't yet defined clearly.  The patch only uses 2 bits, and leaves
the nsecond values at full resolution.

My understanding is that my current patch would be able to handle the
RO_COMPAT_NSEC flag, because for new inodes and existing inodes with
sufficient i_extra_isize it will always store the nsecond timestamps.
I leave it up to mke2fs and/or e2fsck to set this flag and enforce that
ALL inodes in a filesystem can handle nsecond timestamps.

The only other thing this patch is missing (which isn't totally needed)
is to potentially update existing inodes to have a larger i_extra_isize
for holding the new timestamps.  This implies potentially moving the 
EAs further out, which adds some complexity.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.