Re: kern/48449: y2038 shortcomings of ffsv1

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/48449; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
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>
     Message-ID:  <20210616005501.3F1121A923B%mollari.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
 vnode cache.
 
 All of this for a pointless change...
 
 [On my bizarre suggestion to steal the upper 2 bits from the
 nanoseconds field]:
 
   |  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.
 
 kre