Re: kern/48449: y2038 shortcomings of ffsv1

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

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/48449: y2038 shortcomings of ffsv1
Date: Thu, 17 Jun 2021 00:00:02 +0000

 On Wed, Jun 16, 2021 at 09:40:01AM +0000, Robert Elz wrote:
  >    |  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.
 
 Timestamp issues are not a compelling reason 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.
 
 Creating a file is still pretty straightforward. Or you could create
 the file first with enough space in it to serve, then unmount.
 
 And yes, it is simple. Now let me explain undo/redo logging with
 rolling checkpoints...... :-)
 
  >    |  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.
 
 Again, there is absolutely no problem updating existing inodes.
 
  >    |  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.
 
 If you do it starting from the assumption that it's pointless to do
 anything, you aren't likely to get him to disagree :-)
 
 Anyway, truncating to microseconds is probably the best approach of
 the ones discussed so far, and it only requires a flag in the
 superblock, not a whole field.
 
  >    |  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.
 
 You'd need to shuffle all times so they stay in order, at least in
 general. No reason that can't be a kernel patch, but setting the clock
 in a VM is simpler.
 
 It might be possible to _scale_ all the times by a factor of 2 (so
 1980 reads as 1975, 1990 as 1980, etc.) up to some limit like say 24
 hours prior to current (so realtime computations don't go off the
 rails); that would need to be a kernel patch but probably wouldn't be
 all that horrible to do, and could be a compat mode coexisting with
 normal processes as long as the processes in the asylum don't try to
 exchange timestamps with them.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost