Re: Why isn't ext2 deprecated over ext4?

Michael Opdenacker
2024-02-21T16:29:56Z

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