Re: [PATCH v2] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 13, 2021 at 11:14:36AM -0700, Darrick J. Wong wrote:
> > There were only two cases where we created file systems with 128 byte
> > inodes --- "small" and "floppy" sized file systems, and for the GNU
> > Hurd, which only supports the original 128 byte inode.  What will GNU
> > Hurd do in 16.5 years?  ¯\_(ツ)_/¯
> 
> Perhaps in that time someone can donate a disused Opteron 140 system?
> Assuming the motherboard capacitors haven't since lost their mojo.

Apparently GNU Hurd uses a unsigned 32-bit int for time_t, so they
have a 2106 problem.  They "have no plans for a 64-bit userspace, but
they have plans for a 64-bit kernel that can run 32-bit user space".
Comments from the the GNU Hurd folks on an IRC chat from 2013:

    <braunr> which overflows in 2106
    <braunr> and we already include funny comments that predict our successors,
      if any, will probably fail to deal with the problem until short before
      the overflow :>
    <azeem> luckily, no nuclear reactors are running the Hurd sofar

    https://www.gnu.org/software/hurd/open_issues/versioning.html

> > +	/*
> > +	 * Warn the user that filesystems with 128-byte inodes will
> > +	 * not work properly beyond 2038.  This can be suppressed via
> > +	 * a boolean in the mke2fs.conf file, and we will disable this
> > +	 * warning for ext2, ext3, and hurd file systems.
> 
> Um... the conffile changes only disable the warning for Hurd?

Oops, good catch, I'll fix up the comment.

> > +This boolean relation specifies wheather mke2fs will issue a warning
> > +when creating a file system with 128 byte inodes (and so therefore will
> > +not support dates after January 19th, 2038.  The default value is true,
> 
> Nit: need a closing parentheses after '2038' or no opening paren.

Thanks, fixed.

> > +except for file systems created for the GNU Hurd, which does not support
> > +inodes larger than 128 bytes.
> 
> I wonder if this statementt about Hurd this belongs in the conffile as a
> comment in the hurd section?

We currently don't have a Hurd section.  We probably could document
more about the magic that mke2fs does when you specify "-o hurd",
which probably should go in the mke2fs man page but I can't quite
bring myself to care.  Maybe some GNU Hurd folks can get interested to
do this?  :-)

						- Ted



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux