Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> 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.

We know what we are going to do. time_t is required to be an integral
type, so the only option is to boost it to a quad or to leave it as an 
int32. No other options exist. Therefore, when we start the Y2038
fixes, they will be to boost time_t to a quad -- repeating, no other
options exist.

inodes, of course, could use a kludge, but the kernel machinery
ultimately will use 64 bit time_ts.

> Also, what are we going to do about normal-sized inodes and Y2038? Say
> you-loose?

Probably. I'm guessing that we can provide tools to expand your file
system to deal with the situation before another 38 years have passed.

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