2021-08-11 23:34:27

by Darrick J. Wong

[permalink] [raw]
Subject: [PATCH] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs

From: Darrick J. Wong <[email protected]>

Filesystems with 128-byte inodes do not support timestamps beyond the
year 2038. Since we're now less than 16.5 years away from that point,
it's time to start warning users about this lack of support when they
format an ext4 filesystem with small inodes.

First, change the mke2fs.conf file to specify 256-byte inodes even for
small filesystems, then add a warning to mke2fs itself if someone is
trying to make us format an ext4 filesystem with 128-byte inodes.

Note that we /don't/ warn about these things if the user has signalled
that they want an old format such as ext2, ext3, or hurd. Everyone
should know by now that those are legacy.

Signed-off-by: Darrick J. Wong <[email protected]>
---
misc/mke2fs.c | 35 +++++++++++++++++++++++++++++++++++
misc/mke2fs.conf.in | 4 ++--
2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index 92003e11..b16880c2 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1537,6 +1537,30 @@ static int get_device_geometry(const char *file,
}
#endif

+/*
+ * Returns true if the user is forcing an old format (e.g. ext2, ext3).
+ *
+ * If there is no fs_types list, the user invoked us with no explicit type and
+ * gets the default (ext4) format. If we find the latest format (ext4) in the
+ * type list, some combination of program name and -T argument put us in ext4
+ * mode. Anything else (ext2, ext3, hurd) and we return false.
+ */
+static inline int
+old_format_forced(char **fs_types)
+{
+ int found_ext4 = 0;
+ int i;
+
+ if (!fs_types)
+ return 0;
+
+ for (i = 0; fs_types[i]; i++)
+ if (!strcmp(fs_types[i], "ext4"))
+ found_ext4 = 1;
+
+ return !found_ext4;
+}
+
static void PRS(int argc, char *argv[])
{
int b, c, flags;
@@ -2603,6 +2627,17 @@ static void PRS(int argc, char *argv[])
exit(1);
}

+ /* If the user didn't tell us to format with an old ondisk format... */
+ if (!old_format_forced(fs_types)) {
+ /*
+ * ...warn them that filesystems with 128-byte inodes will not
+ * work properly beyond 2038.
+ */
+ if (inode_size == EXT2_GOOD_OLD_INODE_SIZE)
+ printf(
+_("128-byte inodes cannot handle dates beyond 2038 and are deprecated\n"));
+ }
+
/* Make sure number of inodes specified will fit in 32 bits */
if (num_inodes == 0) {
unsigned long long n;
diff --git a/misc/mke2fs.conf.in b/misc/mke2fs.conf.in
index 01e35cf8..2fa1a824 100644
--- a/misc/mke2fs.conf.in
+++ b/misc/mke2fs.conf.in
@@ -16,12 +16,12 @@
}
small = {
blocksize = 1024
- inode_size = 128
+ inode_size = 256
inode_ratio = 4096
}
floppy = {
blocksize = 1024
- inode_size = 128
+ inode_size = 256
inode_ratio = 8192
}
big = {


2021-08-12 00:49:24

by Andreas Dilger

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

On Aug 11, 2021, at 5:32 PM, Darrick J. Wong <[email protected]> wrote:
>
> From: Darrick J. Wong <[email protected]>
>
> Filesystems with 128-byte inodes do not support timestamps beyond the
> year 2038. Since we're now less than 16.5 years away from that point,
> it's time to start warning users about this lack of support when they
> format an ext4 filesystem with small inodes.
>
> First, change the mke2fs.conf file to specify 256-byte inodes even for
> small filesystems, then add a warning to mke2fs itself if someone is
> trying to make us format an ext4 filesystem with 128-byte inodes.
>
> Note that we /don't/ warn about these things if the user has signalled
> that they want an old format such as ext2, ext3, or hurd. Everyone
> should know by now that those are legacy.
>
> Signed-off-by: Darrick J. Wong <[email protected]>

Reviewed-by: Andreas Dilger <[email protected]>

> ---
> misc/mke2fs.c | 35 +++++++++++++++++++++++++++++++++++
> misc/mke2fs.conf.in | 4 ++--
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/misc/mke2fs.c b/misc/mke2fs.c
> index 92003e11..b16880c2 100644
> --- a/misc/mke2fs.c
> +++ b/misc/mke2fs.c
> @@ -1537,6 +1537,30 @@ static int get_device_geometry(const char *file,
> }
> #endif
>
> +/*
> + * Returns true if the user is forcing an old format (e.g. ext2, ext3).
> + *
> + * If there is no fs_types list, the user invoked us with no explicit type and
> + * gets the default (ext4) format. If we find the latest format (ext4) in the
> + * type list, some combination of program name and -T argument put us in ext4
> + * mode. Anything else (ext2, ext3, hurd) and we return false.
> + */
> +static inline int
> +old_format_forced(char **fs_types)
> +{
> + int found_ext4 = 0;
> + int i;
> +
> + if (!fs_types)
> + return 0;
> +
> + for (i = 0; fs_types[i]; i++)
> + if (!strcmp(fs_types[i], "ext4"))
> + found_ext4 = 1;
> +
> + return !found_ext4;
> +}
> +
> static void PRS(int argc, char *argv[])
> {
> int b, c, flags;
> @@ -2603,6 +2627,17 @@ static void PRS(int argc, char *argv[])
> exit(1);
> }
>
> + /* If the user didn't tell us to format with an old ondisk format... */
> + if (!old_format_forced(fs_types)) {
> + /*
> + * ...warn them that filesystems with 128-byte inodes will not
> + * work properly beyond 2038.
> + */
> + if (inode_size == EXT2_GOOD_OLD_INODE_SIZE)
> + printf(
> +_("128-byte inodes cannot handle dates beyond 2038 and are deprecated\n"));
> + }
> +
> /* Make sure number of inodes specified will fit in 32 bits */
> if (num_inodes == 0) {
> unsigned long long n;
> diff --git a/misc/mke2fs.conf.in b/misc/mke2fs.conf.in
> index 01e35cf8..2fa1a824 100644
> --- a/misc/mke2fs.conf.in
> +++ b/misc/mke2fs.conf.in
> @@ -16,12 +16,12 @@
> }
> small = {
> blocksize = 1024
> - inode_size = 128
> + inode_size = 256
> inode_ratio = 4096
> }
> floppy = {
> blocksize = 1024
> - inode_size = 128
> + inode_size = 256
> inode_ratio = 8192
> }
> big = {


Cheers, Andreas






Attachments:
signature.asc (890.00 B)
Message signed with OpenPGP

2021-08-12 01:26:54

by Theodore Ts'o

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

On Wed, Aug 11, 2021 at 04:32:53PM -0700, Darrick J. Wong wrote:
> +/*
> + * Returns true if the user is forcing an old format (e.g. ext2, ext3).
> + *
> + * If there is no fs_types list, the user invoked us with no explicit type and
> + * gets the default (ext4) format. If we find the latest format (ext4) in the
> + * type list, some combination of program name and -T argument put us in ext4
> + * mode. Anything else (ext2, ext3, hurd) and we return false.
> + */

So that's not actually quite right. Even if the user has no explicit
type, mke2fs will assign a default type --- and it's not necessarily
ext4. You can see what the contents of the fs_types list using the -v
option:

% /bin/rm /tmp/foo.img ; mke2fs -vq /tmp/foo.img 8m
fs_types for mke2fs.conf resolution: 'ext2', 'small'
% /bin/rm /tmp/foo.img ; mke2fs -vq -T news /tmp/foo.img 8m
fs_types for mke2fs.conf resolution: 'ext2', 'news'
% /bin/rm /tmp/foo.img ; mkfs.ext4 -vq /tmp/foo.img 8m
fs_types for mke2fs.conf resolution: 'ext4', 'small'
% /bin/rm /tmp/foo.img ; mkfs.ext4 -T huge -vq /tmp/foo.img 8m
fs_types for mke2fs.conf resolution: 'ext4', 'huge'
% /bin/rm /tmp/foo.img ; mkfs.ext4 -o hurd -vq /tmp/foo.img 8m
fs_types for mke2fs.conf resolution: 'ext2', 'small', 'hurd'

Also note that the ext2/ext3/ext4 fs_type will always be in
fs_types[0], so it's not necessary to search the entire list, as the
patch is currently doing:

> + for (i = 0; fs_types[i]; i++)
> + if (!strcmp(fs_types[i], "ext4"))
> + found_ext4 = 1;


Cheers,

- Ted

P.S. Although I'm not aware of anyone actually doing this, if there
mke2fs is installed as mke3fs or mke4fs, that's the equivalent of
mkfs.ext3 and mkfs.ext4. (See the logic in the parse_fs_type
function.) Although perhaps there is some obscure distro somewhere
out there that I don't know about....

2021-08-12 15:23:26

by Darrick J. Wong

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

On Wed, Aug 11, 2021 at 09:25:18PM -0400, Theodore Ts'o wrote:
> On Wed, Aug 11, 2021 at 04:32:53PM -0700, Darrick J. Wong wrote:
> > +/*
> > + * Returns true if the user is forcing an old format (e.g. ext2, ext3).
> > + *
> > + * If there is no fs_types list, the user invoked us with no explicit type and
> > + * gets the default (ext4) format. If we find the latest format (ext4) in the
> > + * type list, some combination of program name and -T argument put us in ext4
> > + * mode. Anything else (ext2, ext3, hurd) and we return false.
> > + */
>
> So that's not actually quite right. Even if the user has no explicit
> type, mke2fs will assign a default type --- and it's not necessarily
> ext4. You can see what the contents of the fs_types list using the -v
> option:

Ok, fair, I'll fix the message. "If the user invoked us with no
explicit type, mke2fs adds some variant of ext* to the type list by
default."

> % /bin/rm /tmp/foo.img ; mke2fs -vq /tmp/foo.img 8m
> fs_types for mke2fs.conf resolution: 'ext2', 'small'
> % /bin/rm /tmp/foo.img ; mke2fs -vq -T news /tmp/foo.img 8m
> fs_types for mke2fs.conf resolution: 'ext2', 'news'
> % /bin/rm /tmp/foo.img ; mkfs.ext4 -vq /tmp/foo.img 8m
> fs_types for mke2fs.conf resolution: 'ext4', 'small'
> % /bin/rm /tmp/foo.img ; mkfs.ext4 -T huge -vq /tmp/foo.img 8m
> fs_types for mke2fs.conf resolution: 'ext4', 'huge'
> % /bin/rm /tmp/foo.img ; mkfs.ext4 -o hurd -vq /tmp/foo.img 8m
> fs_types for mke2fs.conf resolution: 'ext2', 'small', 'hurd'
>
> Also note that the ext2/ext3/ext4 fs_type will always be in
> fs_types[0], so it's not necessary to search the entire list, as the
> patch is currently doing:

But that's not quite right either:

# mke2fs -t small -T ext4 -vqn a.img
fs_types for mke2fs.conf resolution: 'small', 'ext4'

So to find the 'ext4' here, you /do/ have to iterate the whole list.

--D

>
> > + for (i = 0; fs_types[i]; i++)
> > + if (!strcmp(fs_types[i], "ext4"))
> > + found_ext4 = 1;
>
>
> Cheers,
>
> - Ted
>
> P.S. Although I'm not aware of anyone actually doing this, if there
> mke2fs is installed as mke3fs or mke4fs, that's the equivalent of
> mkfs.ext3 and mkfs.ext4. (See the logic in the parse_fs_type
> function.) Although perhaps there is some obscure distro somewhere
> out there that I don't know about....