lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Jun 2020 14:15:05 -0600
From:   Andreas Dilger <>
To:     Reindl Harald <>
Cc:     Ext4 Developers List <>
Subject: Re: ext4 filesystem being mounted at /boot supports timestamps until

On Jun 6, 2020, at 10:45 AM, Reindl Harald <> wrote:
> are you guys kidding me?
> * create a new vmware vdisk with 512 MB
> * kernel 5.7.0, e2fsprogs-1.45.5-1.fc31.x86_64
> * mount the filesystem
> Jun  6 18:37:57 master kernel: ext4 filesystem being mounted at /boot
> supports timestamps until 2038 (0x7fffffff)

Hi Reindl,
It isn't clear if your complaint is about the warning message, or the
fact that this is an issue with the newly-formatted filesystem?  The
*issue* of 2038 timestamps has always existed, but the warning message
is newly added so that people have time to fix this if necessary.

I wonder if it makes sense to add a superblock flag like "yes, I know
this is not 2038 compliant, and I don't care"?

> -----------------------------
> this does *not* happen when the vdisk is 768 MB instead just 512 MB
> large - what's te point of defaults which lead to warnings like this in
> 2020?

This is a matter of space usage. Enabling the 64-bit timestamps requires
that the filesystem be formatted with 256-byte inodes, since there wasn't
enough space in the original 128-byte inodes for the larger timestamps
(among other things).  That means either 1/2 as many inodes for the
filesystem to fit in the same metadata space, or double the amount of
metadata usage for the filesystem (reducing free space).

The assumption is that smaller filesystems like this are unlikely to be
used for storing long-term data, so maximizing the usable space is most
important.  It is unlikely you will be using the same /boot filesystem
in 18 years, and if you are it is even less likely that it is being
updated on a regular basis.

It is possible to enable the larger inodes for any size filesystem by
formatting with "mk2fs -I 256 <other options> <device>".  See "man mke2fs"
for full details.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)

Powered by blists - more mailing lists