Re: Why isn't ext2 deprecated over ext4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux