On Thu, 25 Mar 1999, Ted Lemon wrote:

> I'm not concerned about the flags - I'm concerned about where the data
> goes.  There shouldn't really be flags to indicate that we're using a
> fat date - the date should just be stored differently in the new
> inode, or not.   Having the filesystem code behaviour WRT dates
> conditionalized based on a flag in the inode makes no sense to me at
> all.

The reason it makes sense to me is that we haven't figured out yet what we
are doing about 64-bit times. There is NO machinery in the kernel (that I
have seen) to do it - so we have no current/prior art.

Also, what are we going to do about normal-sized inodes and Y2038? Say
you-loose? If we aren't going to say that, then why should large inode
ufs do Y2038 dates differently than small ones?

If we come up with a way to deal with Y2038 dates in 128-byte inodes, then
all we have to do is bump the inode version number (ffs already can deal
with this). 256-byte inodes can then do the same thing, at the same
version number.


To better flesh out this question, do we REALLY need nanosecond-resolution
times in the fs? Because if we can live with something smaller, like
millisecond or 100 microsecond resolution, then we can drop the
{a,m,c}timensec fields, stick 64-bit times there, and stash the sub-second
fields somewhere else.

Or, just bump the inode versions, and consider the Xtime,Xtimensec a
64-bit number. Bit field it into a 20-bit field and a 44-bit field. Use
the 20-bit field for sub-second times. 2^20-1 is over a million, so we
could store millisecond resolution there. A 44-bit year field would give
us until year 559446 (even though we'd be using signed 64-bit numbers to
specify times to the fs at that point, we don't need to keep these times
in the inode as signed quantities).

Things like boot loaders would still be happy, since I think they ignore
times, and everything else is the same.

I'm not saying we HAVE to make this change, just that ther are ways, other
than requiring large inodes, to solve the Y2038 problem. So to postpone
solving the Y2038 problem makes sense to me - so that we don't throw in a
fix until we've decided what is the best thing to do. And so that 128-byte
and 256-byte indoes do the same thing. :-)

Take care,

Bill