All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v2] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs
Date: Fri, 13 Aug 2021 15:32:48 -0400	[thread overview]
Message-ID: <YRbI4E3b42X3otJv@mit.edu> (raw)
In-Reply-To: <20210813181436.GZ3601466@magnolia>

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

  reply	other threads:[~2021-08-13 19:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12 23:22 [PATCH v2] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs Darrick J. Wong
2021-08-13 17:52 ` Theodore Ts'o
2021-08-13 18:14   ` Darrick J. Wong
2021-08-13 19:32     ` Theodore Ts'o [this message]
2021-08-13 19:34       ` [PATCH -v4] " Theodore Ts'o
2021-08-13 19:35         ` Theodore Ts'o
2021-08-13 19:35       ` [PATCH -v5] " Theodore Ts'o
2021-08-13 20:31         ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRbI4E3b42X3otJv@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=djwong@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.