Greetings
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.
Thanks in advance
Cheers
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Am 21.02.24 um 10:33 schrieb Michael Opdenacker:
> Greetings
>
> 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.
even ext4 on very small filesystems has 32 bit days
at least in 2019 a fresh 50 MB filesystem welcomed me at first mount
that it will only last until 2038 - i don't find the mail in my archives
but the response on the kernel-list was "add these and that params"
after i asked if someone is kidding me
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.
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.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Am 21.02.24 um 12:00 schrieb Jan Kara:
> 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.
>
> 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.
you shouldn't create filesystems with a on-disk format that don't
support 64bit timestamps no matter how small the filesystem is
the arguments on this list where "such a small filesystem isn't expected
to be still used in 2038" which is nonsense in case of a /boot FS in a
virtual machine
our whole servers already survived 16 years and 30 dist-upgrades
On Wed, Feb 21, 2024 at 12:39:54PM +0100, Reindl Harald wrote:
>
> you shouldn't create filesystems with a on-disk format that don't support
> 64bit timestamps no matter how small the filesystem is
>
> the arguments on this list where "such a small filesystem isn't expected to
> be still used in 2038" which is nonsense in case of a /boot FS in a virtual
> machine
>
> our whole servers already survived 16 years and 30 dist-upgrades
This is an individual system administrator's decision. The defaults
will not create file systems with 128 byte inodes.
However, there are situations where it *does* make sense to use ext4
file systems that can not express timestamps past 2038. For example,
at my employer, 128 byte inodes on HDD's because we do *not* preserve
file system images across hardware upgrades. Using 128 byte inodes
means that there are 32 inodes per 4k inode table block, as opposed to
only 16 inodes if you are using a 256 byte inode. There are
performance benefits if you are concerned about reducing the 99.99%
latency on heavily loaded disks, and reducing the TCO costs for bytes
and IOPS for my employer's cluster file system.
Furthermore, from an ecological perspective in terms of power and
cooling perspective, even *if* hard drives would survive for over 8-10
years, it would be irresponsible to keep those systems in service. So
my employer knows what it is doing when it uses explicit mke2fs
options and/or mke2fs.conf settings to create file systems with 128
byte inodes.
- Ted
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
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 <[email protected]>
SUSE Labs, CR
On Wed, Feb 21, 2024 at 05:58:05PM +0100, Jan Kara wrote:
> 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).
Well, if we *cared* we could backport the support for the expanded
timestamps to ext2. I'm not sure it's worth the effort, but it's not
that hard....
- Ted
Am 21.02.24 um 16:48 schrieb Theodore Ts'o:
> On Wed, Feb 21, 2024 at 12:39:54PM +0100, Reindl Harald wrote:
>>
>> you shouldn't create filesystems with a on-disk format that don't support
>> 64bit timestamps no matter how small the filesystem is
>>
>> the arguments on this list where "such a small filesystem isn't expected to
>> be still used in 2038" which is nonsense in case of a /boot FS in a virtual
>> machine
>>
>> our whole servers already survived 16 years and 30 dist-upgrades
>
> This is an individual system administrator's decision. The defaults
> will not create file systems with 128 byte inodes.
it was *not* my decision in 2019 after create a small /boot partition to
get a welcome message at boot that it will not survive 2038
> However, there are situations where it *does* make sense to use ext4
> file systems that can not express timestamps past 2038. For example,
> at my employer, 128 byte inodes on HDD's because we do *not* preserve
> file system images across hardware upgrades.
*this* should be an individual decision instead create outdated nonsense
these days
> Using 128 byte inodes
> means that there are 32 inodes per 4k inode table block, as opposed to
> only 16 inodes if you are using a 256 byte inode. There are
> performance benefits if you are concerned about reducing the 99.99%
> latency on heavily loaded disks, and reducing the TCO costs for bytes
> and IOPS for my employer's cluster file system.
irrelevant on a very small partition
> Furthermore, from an ecological perspective in terms of power and
> cooling perspective, even *if* hard drives would survive for over 8-10
> years, it would be irresponsible to keep those systems in service. So
> my employer knows what it is doing when it uses explicit mke2fs
> options and/or mke2fs.conf settings to create file systems with 128
> byte inodes.
in my world drives don't matter and the systems are moved between
hardware because hardware don't matter at all
what exactly is irresponsible in keeping a up-to-date system in service
which was originally installed 10 or 15 years ago? this isn't microsoft
windows and i haven't installed any Linux from scratch in my whole lifetime
in fact i created a small partition without touching mke2fs.conf and it
ended with a filesystem not surviving past 2038
Fedora for sure didn't invent the nonsense in "mke2fs.conf" falling back
to such pervert settings for very small martitions
On Wed, Feb 21, 2024 at 11:57:22PM +0100, Reindl Harald wrote:
>
> Fedora for sure didn't invent the nonsense in "mke2fs.conf" falling back to
> such pervert settings for very small martitions
So first lf all, "very small" means "smaller that 512 megs". The
rationale was to reduce the overhead for small thumb drives, where
maximizing space for data files was considered most important.
In practice, most root file systems tend to be larger than 512 megs.
For example, the absolute minimum EBS size in Amazon's cloud is 1GiB
for General Purpose SSD backed EBS, and 5GiB for HDD backed EBS.
Google Compute Engine's minimum Persistent Disk size is 10 GiB.
In any case, starting in e2fsprogs 1.46.4 (released August 2021, first
shipped in Fedora 36), we changed the default so that 256 byte inodes
is used everywhere, including these small file systems.
If you didn't like the old default, well, for these really small file
systems, the good news is that it's pretty simple to backup, reformat,
and restore the file system. (And of course, when the root file
system is that small, in general reinstalling it is no big deal.)
Cheers,
- Ted