[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240221154858.GA594407@mit.edu>
Date: Wed, 21 Feb 2024 10:48:58 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Reindl Harald <h.reindl@...lounge.net>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Why isn't ext2 deprecated over ext4?
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
Powered by blists - more mailing lists