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: Wed, 16 Jun 2021 00:52:32 +0000

 On Sat, Jun 12, 2021 at 11:45:02AM +0000, Robert Elz wrote:
  >    |  Your argument seems to be that ffsv1 should be deprecated entirely;
  >  
  >  Almost entirely.   Removed from the kernel (at about the end of this
  >  century -- none of us will ever see it happen... (probably))
  >  [...]
 
 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.
 
  >    |  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.
  >  
  >  ["this" is changing the time offset in a FFSv1 filesystem]
  >  
  >  It terms of implementation complexity, no, that's easy.   The problem is
  >  that this conversion requires touching every (allocated) inode in the
  >  filesystem, and that takes time (human measurable time) and so must be
  >  done in a way that's restartable.   The only way that really works for
  >  this is [...]
 
 Eh, it's a very simple exercise in journaling. Create a file
 /.epoch (or something), write the old and new epochs into it, fsync.
 Then for each cylinder group, read all the inodes, write the
 timestamps into /.epoch, fsync it, then update the inodes one at a
 time, then sync and go on to the next cylinder group. At the end,
 update the epoch in the superblock and delete /.epoch.
 
 If you crash, on restart you read /.epoch and resume updating the
 inodes in the last cylinder group you were working on. You can tell
 which ones got updated and written out before the crash because you
 wrote out all the original timestamps before you started changing
 them.
 
  >  Incidentally there's another unbelievably gross hack that could be done
  >  to extend the time range of FFSv1 (from 136 years or whatever, to > 500
  >  years) ... each of the time fields is really 2 32 bit values.  One for the
  >  (old) time_t (seconds) which is the one that is causing all of these
  >  problems, the other is the nanoseconds field (seconds+nanoseconds == the
  >  timestamp).  One property of nanoseconds is that their range of values
  >  is 0..999999999 (they're never negative in this use) and 999999999
  >  only takes 30 bits to represent.   That means we have two currently
  >  always zero bits associated with each time field in every inode (the
  >  "last write time" fields in the superblock and cylinder groups don't
  >  have this I think, but there are other spare bits in those things
  >  which could be co-opted).
 
 Or truncate to microseconds, which gives 12 extra bits.
 
  >    |  The biggest costs of either of these approaches (or any other) are (a)
  >    |  negotiating the on-disk format change and
  >  
  >  That's this discussion, right?
 
 No, that's agreeing with FreeBSD on what the exact on-disk format
 change should be, so that interoperability remains.
 
  >  Since I see no way (certainly none that has been suggested, including mine)
  >  which has any potential of being issue free, that is the cost that really
  >  matters, and the only way I see to be rid of that is to be rid of FFSv1
  >  (as a first class object that anyone can simply use).
 
 By that standard we should be rid of everything else too :-)
 
  >  ps: when considering 2038 issues, while dealing with 32 bit times in
  >  FFSv1 is a problem, a much bigger problem approaching in 2038 is what
  >  happens with old applications linked with libs that use the 32 bit time_t
  >  interfaces everywhere.   That one we cannot simply wiggle our noses at and
  >  magically cause things to alter - those applications know the range of
  >  a (32 bit) time_t, and aren't going to alter themselves.
 
 They will break, or need to be run in a VM that lives in the past.
 Nothing can reasonably be done about that.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost