Re: Why isn't ext2 deprecated over ext4?

From: Michael Opdenacker <michael.opdenacker@bootlin.com>
To: Jan Kara <jack@suse.cz>
Cc: michael.opdenacker@bootlin.com, linux-ext4@vger.kernel.org
Subject: Re: Why isn't ext2 deprecated over ext4?
Date: Wed, 21 Feb 2024 17:29:48 +0100	[thread overview]
Message-ID: <192cb320-2ded-4761-b0c9-3e273931f6f6@bootlin.com> (raw)
In-Reply-To: <20240221110043.mj4v25a2mtmo54bw@quack3>

Hi Honza, all

Thanks for sharing all these details. See my follow-up questions below...

On 2/21/24 at 12:00, Jan Kara wrote:
> Hello,
>
> On Wed 21-02-24 10:33:04, Michael Opdenacker wrote:
>> I'm wondering why ext2 isn't marked as deprecated yet as it has 32 bit dates
>> and dates will rollover in 2038 (in 14 years from now!).
>>
>> I'm asking because ext4, when used without a journal, seems to be a worthy
>> replacement and has 64 bit dates.
>>
>> I'll be happy to send a patch to fs/ext2/Kconfig to warn users.
> For all practical purposes I agree we expect users to use ext4 driver on a
> filesystem without a journal instead of ext2 driver. We are still keeping
> ext2 around mostly as a simple reference filesystem for other fs
> developers. I agree we should improve the kconfig text to reference users
> to ext4.

I can submit some changes to the Kconfig file along these lines, thanks!

>
> Regarding y2038 problem - this is really the matter of on-disk format as
> created by mke2fs, not so much of the kernel driver. And the kernel will be
> warning about that when you mount ext2 so I don't think special handling is
> needed for that.

So, if I understand correctly, it's mke2fs that should be creating a 
filesystem with 64 bit dates, which the ext2 kernel driver could happily 
support, right? However, I made an experiment by using "mkfs.ext2 -I 
256" and I still got the warning:

[  689.213780] ext2 filesystem being mounted at /mnt supports timestamps 
until 2038-01-19 (0x7fffffff)

"tune2fs -l" also confirmed I had 256 byte inodes. Anything else I 
should pass to mkfs.ext2 to get 64 bit dates in ext2?

By the way, the code shows that the warning is issued 30 years ahead of 
time!
https://elixir.bootlin.com/linux/v6.8-rc5/source/include/linux/time64.h#L43

I also could check, with "busybox ls",  that if I cross the 2038-01-19 
03:14:07 date barrier, all the new files I create on an ext2 filesystem 
stick to that date, instead of rolling over to 1901 as I expected. 
That's better :)

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com