[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/48449: y2038 shortcomings of ffsv1
The following reply was made to PR kern/48449; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: kern/48449: y2038 shortcomings of ffsv1
Date: Wed, 16 Jun 2021 16:34:38 +0700
Date: Wed, 16 Jun 2021 00:55:01 +0000 (UTC)
From: David Holland <dholland-bugs%netbsd.org@localhost>
| Maybe. However, to keep it even that long something has to be done
| about the timestamps, and there's no compelling reason to do a
| halfassed job of that.
Not half assed, just simple, correct, and all that is actually needed.
There is zero reason to keep supporting building new general purpose
FFSv1 filesystems into the indefinite future. There are plenty of
reasons not to.
| Eh, it's a very simple exercise in journaling.
That's not simple, and seems to require doing the modifications to a
running filesystem (otherwise "create a file" is not nearly as simple,
and in any case doesn't work for full filesystems). On a running
filesystem you also need to deal with inodes that are currently in the
All of this for a pointless change...
[On my bizarre suggestion to steal the upper 2 bits from the
| Or truncate to microseconds, which gives 12 extra bits.
That would also require modifying the existing inodes, which really
is the one thing that we don't want to require. And while that would
possibly allow FFSv1 to outlast humanity (> half a million years), I don't
see any point keeping it beyond the end of this century, and certainly
not beyond the 500 year range that 2 extra bits would provide (not that
doing that is rational either).
| No, that's agreeing with FreeBSD on what the exact on-disk format
| change should be, so that interoperability remains.
OK. And of the various suggestions that have been made here, which do
you believe that they're more likely to agree to?
I will talk to Kirk about it.
| They will break, or need to be run in a VM that lives in the past.
| Nothing can reasonably be done about that.
Hmm - I wonder if the "VM that lives in the past" could be the kernel with
a hack to shuffle time in some way - I'm not sure it is really possible
to deal with stat() of a file modified in 2020 and time() returning a
value indicating that the current year is 1985 though. "break" is looking
more and more probable... Sad.
Main Index |
Thread Index |