> >  > Or we could do another gross hack that is even less intrusive.
> >  > If we declare the times in seconds in the inodes to be UNSIGNED, we
> >  > gain another 68 years.
> > ...but you still have to version the inode.
> Unfortunately true... And if we're going to do that, we might as well go
> for the gusto and make a longer-term fix.

One could argue that you might be able to get away without versioning the
inode for this particular change.

Consider:  no existing inodes should have the high-order bit set in the
time, so existing filesystems are treated correctly by updated code.  The
reverse isn't true, of course, but it will be over 38 years before any
systems will have the opportunity to misunderstand a "new" inode (except,
of course, for deliberate tests or the occasional accident where someone
sets their clock WAY too far forward -- once that becomes possible,
of course!).

On the other hand, if you're going to bum ONE bit, the "nanosecond" field has
two bits it shouldn't be using, but you definitely WOULD have to version the
inode to treat the time fields as 64-bit unsigned fixed-point numbers --
but that would delay the day of reckoning to 2514 AD, so at least no one
here is likely to be personally embarassed when it breaks. ;-)  (I'm not
willing to be hideous enough to suggest glueing those two (presumably 0)
bits on the high end of the time and re-applying the argument of the above
paragraph...)