linux-ext4 - Re: ext4 filesystem being mounted at /boot supports timestamps until 2038

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 8 Jun 2020 22:24:25 +0200
From:   Reindl Harald <h.reindl@...lounge.net>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: ext4 filesystem being mounted at /boot supports timestamps until
 2038



Am 08.06.20 um 22:15 schrieb Andreas Dilger:
> On Jun 6, 2020, at 10:45 AM, Reindl Harald <h.reindl@...lounge.net> 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)
>>
>> https://lore.kernel.org/patchwork/patch/1172334/
> 
> 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.

that it even is an issue with a newly-formatted filesystem in 220

> 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"?

well, more or less i case because i expect that setups to still live in
2038 and it's unclear what happens then

>> -----------------------------
>>
>> 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).

none of that would have mattered

Filesystem           Type            Size      Used Available Use%
Mounted on
/dev/root            ext4          738.9M     54.0M    669.6M   7% /

> The assumption is that smaller filesystems like this are unlikely to be
> used for storing long-term data

adventurous assumption

> 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.

why wouldn't it on virtual machines?

most of my stuff has the same golden master from 2008 as source and is
running happily the newest kernel and newest Fedora release

in the case with the new formatted filesystem it was even the rootfs
which was a 6 GB vdisk and i created a new one and copied the whole data
while mounte dfrom a different vm

> 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.

well, i decided to go from 512 MV to 768 MB which is at least magnitudes
smaller than 6 GB and don't throw warnings at the first mount