Received-SPF: pass (google.com: domain of linux-ext4+bounces-1340-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 21 Feb 2024 17:58:05 +0100
From: Jan Kara <jack@suse.cz>
To: Michael Opdenacker <michael.opdenacker@bootlin.com>
Cc: Jan Kara <jack@suse.cz>, linux-ext4@vger.kernel.org
Subject: Re: Why isn't ext2 deprecated over ext4?
Message-ID: <20240221165805.plnkvymjzqts2l6r@quack3>
References: <bcaf9066-bb4a-4db3-b423-c9871b6b5a2f@bootlin.com>
 <20240221110043.mj4v25a2mtmo54bw@quack3>
 <192cb320-2ded-4761-b0c9-3e273931f6f6@bootlin.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <192cb320-2ded-4761-b0c9-3e273931f6f6@bootlin.com>

Hello!

On Wed 21-02-24 17:29:48, Michael Opdenacker wrote:
> On 2/21/24 at 12:00, Jan Kara wrote:
> > 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!

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?

Hum, so I didn't quite think through my comment about on disk format :).
When you create filesystem with larger inodes, mke2fs will indeed create
inodes with extra timestamp fields etc. ext4 driver will recognize them
and use them, however ext2 driver happily ignores them (I thought we refuse
to mount such filesystem but we don't because of the way how large inodes
were defined in the ondisk format).

In any case the ext2 driver does not really support handling of larger
timestamps. If you want y2038 safety, you must use the ext4 driver.

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

Yes, but all files created in 1971 will magically appear to be created in
2038 when you cross that date :).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR