Re: kern/48449: y2038 shortcomings of ffsv1

[David Holland <dholland%netbsd.org@localhost>]

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

From: David Holland <dholland%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/48449: y2038 shortcomings of ffsv1
Date: Fri, 11 Jun 2021 22:31:10 +0000

 On Thu, Jun 10, 2021 at 11:30:02AM +0000, Robert Elz wrote:
  > |  Or, much more simply, store a 64-bit epoch in the superblock (this
  > |  lets you pick it at newfs time) and add the 32-bit times to it. This
  > |  requires adding a superblock field but we can probably afford that.
  >  
  > No, that's is almost the worst of all possible solutions (even
  > including just doing nothing).  It is simple and easy to implement
  > in the steady state, but the transition mechanism is horrid.  If
  > you really meant *only* at newfs time, then it is a waste of
  > effort, anyone doing a newfs can set -O2 and the issue doesn't
  > arise.  The problem is with all the existing FFSv1 filesystems, not
  > new ones (and doing a dump/restore to handle the problem is way too
  > invasive, and risky).
 
 No. Unless ffsv1 is deprecated entirely, some way to store a wider
 range of dates needs to be hacked in -- it is not reasonable to try to
 use a filesystem that can't store the current date.
 
 Your argument seems to be that ffsv1 should be deprecated entirely;
 that's fine if we can pull it off, but given that among other things
 there are machines with ffs-reading firmware that don't understand
 ffsv2, probably isn't realistic.
 
 Conversely, I was assuming that only new volumes matter and that's
 probably also not true.
 
  > While it is possible to set up a method whereby the offset can be
  > added to (or changed in, which is the same thing) an existing
  > filesystem, doing it is far more complex than is needed, as
  > maintaining constant timestamps means that if the offset alters, so
  > must every timestamp in every inode, and as that can't be done
  > instantaneously, there's the possibility that the filesystem might
  > get into a state where some inodes have been converted, and others
  > not, which means inodes would need a state bit (old or new offset)
  > and the superblock would need two new offset fields.  All a giant
  > mess.
 
 It's not hard to do this and do it in a way that's adequately
 recoverable/restartable. It's nowhere near as complicated as
 resize_ffs.
 
  >  Further, no matter what is done, a FFSv1 cannot store a range of timestamps
  >  that spans more than 140 years (approx), so any solution needs to live with
  >  that - which really means that we need to make FFSv1 vanish by 2100 or so.
  >  That is aside from perhaps access to some ancient filesystems in read only
  >  (or at least no time update) mode.
 
 Maybe. It isn't clear that large timespans are necessary in practice,
 especially for system volumes, where ordinarily nothing is older than
 the original OS install. (And it doesn't matter if unpacking some
 200-year-old 3rd-party source tarball to build it gives it all
 timestamps of INT_MIN.)
 
 Maybe in two hundred years people will have heirloom dirs full of
 their grandparents' MS Word files, but I wouldn't be surprised if
 most people didn't care in practice about timestamps older than they
 are.
 
  > A very simple solution which will give us time to phase out (most,
  > see below for the workaround) FFSv1 completely (within another
  > 80/90 years from now) is to add a single extra bit to the
  > superblock, which, when set, indicates that all times stored in the
  > filesystem are unsigned.  That alters the range of times from
  > 1907..2038 to 1970..2100 (give or take) instantly.
 
 If one is going to change the on-disk format at all, it's best to not
 do it halfassedly. In the computer biz doing things halfassedly is
 almost always a mistake, especially in the long term.
 
 The biggest costs of either of these approaches (or any other) are (a)
 negotiating the on-disk format change and (b) identifying all the code
 paths in the system that need adjustment; these cost pretty much the
 same no matter what the change is.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost