Re: [RFC] nanoseconds vs. the epoch

Hi,

On Fri, 2006-06-02 at 11:57 -0600, Andreas Dilger wrote:

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

But that's not the question I'm asking --- I'm asking whether we want to
perform any epoch extension on existing 128-byte inodes.  If we do, then
any further extension using bits from the ns timestamps has to be
incremental on top of that.

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

I think we need a long, hard think about that whole issue before we go
much further down this path.  I'd rather reserve a chunk of space in the
extra_size region in advance so that we can assign future fields
cleanlyu.  Because if we rely on growing the extra_size fields
dynamically, then there will always be easily-exploitable edge cases
where the inode simply has no room left (the current EA mechanism lets
you fill *both* the inode unused space *and* the entire EA block with
xattrs.)

--Stephen