31 years after the start of its career in 1993, it’s time for ext2 to retire. Here we are talking about the driver for this filesystem, not exactly the filesystem itself. Continue reading to understand the subtle difference.
It’s the ext2 filesystem driver that will be marked as deprecated in the upcoming 6.9 Linux kernel. The main issue is that even if the filesystem is created with 256 byte inodes (mkfs.ext2 -I 256), the filesystem driver will stick to 32 bit dates. Because of this, the driver does not support inode timestamps beyond 03:14:07 UTC on 19 January 2038.
By the way, if you are still using ext2 and its driver, and your system date is set correctly to a date at most 30 years before the deadline, you will get this warning:
# mount -t ext2 /dev/sda1 /mnt [ 441.680685] ext2 filesystem being mounted at /mnt supports timestamps until 2038-01-19 (ox7fffffff)
I checked this by myself, by setting my system date to several dates in the future:
# date -s "2029-02-24 03:13:30" Sat Feb 24 03:13:30 UTC 2029 # touch /mnt/foo1 # date -s "2038-01-18 03:13:30" Mon Jan 18 03:13:30 UTC 2038 # touch /mnt/foo2 # date -s "2038-01-20 03:13:30" Wed Jan 20 03:13:30 UTC 2038 # touch /mnt/foo3 # date -s "2048-01-20 03:13:30" Mon Jan 20 03:13:30 UTC 2048 # touch /mnt/foo4 # ls -la /mnt drwxr-xr-x 3 0 0 4096 Jan 19 2038 . drwxrwxr-x 13 1000 1000 4096 Feb 20 2024 .. -rw-r--r-- 1 0 0 0 Feb 24 2029 foo1 -rw-r--r-- 1 0 0 0 Jan 18 2038 foo2 -rw-r--r-- 1 0 0 0 Jan 19 2038 foo3 -rw-r--r-- 1 0 0 0 Jan 19 2038 foo4
As you can see, the last files created after the deadline are stuck with the same date. This will most certainly cause problems in several programs.
Users are advised to mount their filesystem with the ext4 driver. The ext4 filesystem driver is fully compatible with ext2, though the filesystem will remain an ext2 one.
First, make sure that you don’t have a 128 bytes inode size, which corresponds to 32 bit dates:
# sudo tune2fs -l /dev/sda1 | grep "Inode size" Inode size: 128
If that’s the case, it is possible to increase the inode size:
# sudo e2fsck -f /dev/sda1 e2fsck 1.46.5 (30-Dec-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information ext2test: 14/477664 files (0.0% non-contiguous), 19254/1904816 blocks # sudo tune2fs -I 256 /dev/sda1 tune2fs 1.46.5 (30-Dec-2021) Resizing inodes could take some time. Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y Setting inode size 256
Note that if you create your filesystem with mkfs.ext2 (at least from e2fsprogs version 1.46.5 in Ubuntu 22.04), the filesystem is created with 256 bit inodes anyway:
mkfs.ext2 /dev/sda1
So, if you mount it with the ext4 driver, it will remain an ext2 filesystem but will support 64 bit dates!
By the way, using the ext4 filesystem directly (instead of mounting ext2 through the ext4 driver), is also a relevant option, as it can work without a journal and extents for small partitions. For example, pass the -O ^has_journal option to mkfs.ext4 to create an ext4 filesystem without a journal.
Note that if you really miss the ext2 driver and its simplicity, it’s not too late to make it support 64 bit dates. Kernel developer Ted T’so said it wouldn’t be so difficult to implement.
See the whole discussion that led to this change.
NIT: The indentation of the help text looks wrong (the two lines starting with “or extents”)
Oops, correct, not the same use of spaces and tabs. Too late, and this doesn’t appear in “menuconfig”. Thanks anyway!
Sorry if it’s a stupid question, but… why not have the driver outright removed? I mean, you said that ext4 driver is fully compatible with it, so basically you have two drivers for the same functional, except one is future-proof and widely used and the other one neither. So why bother with deprecation?
Maybe because it’s good to leave time between the time a driver is deprecated and when it’s removed. This way, you don’t break the configurations that use it.
Another argument was that it would be feasible to add 64 bit date support to the ext2 driver. So, keeping the driver while deprecating it may allow this to happen, and cancel the deprecation.
> Maybe because it’s good to leave time between the time a driver is deprecated and when it’s removed. This way, you don’t break the configurations that use it.
How do you imagine such dependency? Usually people rely on specific kernel driver because it provides some special functional. I just looked at `modinfo ext2 | grep parm` on my Arch with 6.8.2 kernel and it’s empty. So ext2 provides no module options that somebody could’ve relied upon. Another reason would be something special in someone’s `fstab` file, but I just looked through `man fstab` and it doesn’t seem to support choosing a driver explicitly.
So… what gives?