Is this the equivalent of a PC maker in 2024 going "yeah, I don't think we are going to put a floppy drive in anymore..."?
No. It is the equivalent of a PC maker going "yeah. I don't think we are going to put in a CD drive anymore because the DVD drive we have been including for years can do CDs as well"
That is a great analogy.
Linux can support ext2 two ways today: explicitly and as a side effect of ext4 support. All this change does is remove the explicit support.
We can remove the explicit CD support provided by a dedicated drive because the DVD drive will provide it as a side-effect.
It's not a new thing.
Linux Kernel Drops Support For Old Intel 386 CPUs
Written by Michael Larabel in Linux Kernel on 12 December 2012 at 10:33 AM EST. 31 Comments
https://www.phoronix.com/news/MTI0OTg
I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.
The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.
I hope Slackware 15 doesn't still recommend ext2 for being "fast and stable" like Slackware 14 did, so at least until the start of 2022.
That reminds me that some howtos I've seen in the past recommended to use ext2 for a separate /boot partition.
Now we use fat on the ESP. Ext2 for boot was pretty common in the past, journaling wasn’t really needed and it was going to work with whichever bootloader you used. At the time your other partitions might use who knows what and bootloader support for that filesystem wasn’t guaranteed.
Depends how you read that. FAT32 is basically required for /boot/EFI but you still see /boot as separate old, stable filesystem on some setups. Usually it is just a bit easier/less hassle to do the whole thing up as FAT32 but you don’t have to.
Perhaps for LILO compatibility? But that would make it a pretty old howto (10 years or more).
Just use ext3 with journaling turned off.
So should ext3 be deprecated for the same reason? Seems it also has the 2038 problem.
I love ZFS but support for it on Ubuntu seems haphazard. It works fine for non-root drives.
I've tried running it as my root partition and just gave up after it fucked up my bpool dataset too many times.
Dis you use the ZFS setup built into the installer?
Yup. It booted fine but after a few reboots, bpool somehow got corrupted and refused to boot. It happened repeatedly after several reinstalls.
ZFS hits memory hard and sometimes can bring out latent deficiencies in that hardware. on non-optimal hardware its a bit of a hardware torture test in its own right.
having said that, EXT4 and XFS are wonderful unless you need zfs/btrfs.
Always run 3-4 passes of Memtest86+ on any newly acquired hardware/RAM modules.
Yeah, the current implementation from the installer never got beyond the experimental stage when it was first introduced. I saw there's a new "guided setup" in the 24.04 release notes. No idea what it entails yet. I think I've also seen a page for setting it up for / in OpenZFS'es docs. I might try it at some point.
Same here lol, just read through ext{2..4} as well as Btrfs and Bcachefs (and B Trees of course). What a wonderful unplanned deep dive.
Bcachefs sounds awesome
ZFS is really nice. I started experimenting with it when it was being introduced to FreeBSD, around 2007-2008, but only truly started using it last year, for two NASes (on Linux).
It's complex for a filesystem, but considering all it can do, that's not surprising.
ZFS is boss. I'm already using it for storage. Need to learn how to use it for /.
Not recommended for single-disk root partitions. This is a mistake I've made myself. Recovery tools are non-existant on ZFS so non-parity setups are inherently risky. If you have root setup on at least raidz1 with at least 2 disks you are fine.
Personally I wouldn't consider recovery as an option at all because it could easily be unavailable because the SSD failed. Instead, I tend to add a mirror drive and/or keep frequent backups where that's not possible. So from that perspective ZFS is equivalent to Ext4, which I currently use. I'd prefer ZFS over it for it's data verification, snapshotting and datasets features.
I've successfully recovered data from ext4 on a broken drive on one occasion. I agree it would have been better to have backups so lesson learned I suppose. Still if I'd been on ZFS root with no mirror I'd have been even more SOL
The ext4 driver can read ext2/ext3 partitions while supporting the 2038 time issue
The only change here is the driver loading the filesystem
Ext3 support is already only available through the ext4 driver
You will still be able to mount an ext2 file system with the kernel until ext4 support is removed. That is still going to be a long, long time.
Nice, can we just do the same with ext3 and ext4 now?
Wow, 1993 to 2024, not a bad first-class support lifetime.
https://en.wikipedia.org/wiki/Ext2
Is this the equivalent of a PC maker in 2024 going "yeah, I don't think we are going to put a floppy drive in anymore..."?
No. It is the equivalent of a PC maker going "yeah. I don't think we are going to put in a CD drive anymore because the DVD drive we have been including for years can do CDs as well"
That is a great analogy.
Linux can support ext2 two ways today: explicitly and as a side effect of ext4 support. All this change does is remove the explicit support.
We can remove the explicit CD support provided by a dedicated drive because the DVD drive will provide it as a side-effect.
It's not a new thing.
I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.
The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.
I hope Slackware 15 doesn't still recommend ext2 for being "fast and stable" like Slackware 14 did, so at least until the start of 2022.
That reminds me that some howtos I've seen in the past recommended to use ext2 for a separate /boot partition.
Now we use fat on the ESP. Ext2 for boot was pretty common in the past, journaling wasn’t really needed and it was going to work with whichever bootloader you used. At the time your other partitions might use who knows what and bootloader support for that filesystem wasn’t guaranteed.
Depends how you read that. FAT32 is basically required for
/boot/EFIbut you still see/bootas separate old, stable filesystem on some setups. Usually it is just a bit easier/less hassle to do the whole thing up as FAT32 but you don’t have to.Perhaps for LILO compatibility? But that would make it a pretty old howto (10 years or more).
Just use ext3 with journaling turned off.
So should ext3 be deprecated for the same reason? Seems it also has the 2038 problem.
https://en.wikipedia.org/wiki/Ext3
E: Seams -> Seems
If I recall correctly, ext3 is ext2 with journalling on top, so they can't really get rid of ext2 without also ditching ext3.
Thanks for that! which made me read https://en.wikipedia.org/wiki/Ext3#ext4 Maybe high time for myself to learn more about ZFS.
I love ZFS but support for it on Ubuntu seems haphazard. It works fine for non-root drives.
I've tried running it as my root partition and just gave up after it fucked up my bpool dataset too many times.
Dis you use the ZFS setup built into the installer?
Yup. It booted fine but after a few reboots, bpool somehow got corrupted and refused to boot. It happened repeatedly after several reinstalls.
ZFS hits memory hard and sometimes can bring out latent deficiencies in that hardware. on non-optimal hardware its a bit of a hardware torture test in its own right.
having said that, EXT4 and XFS are wonderful unless you need zfs/btrfs.
Always run 3-4 passes of Memtest86+ on any newly acquired hardware/RAM modules.
Yeah, the current implementation from the installer never got beyond the experimental stage when it was first introduced. I saw there's a new "guided setup" in the 24.04 release notes. No idea what it entails yet. I think I've also seen a page for setting it up for / in OpenZFS'es docs. I might try it at some point.
Same here lol, just read through ext{2..4} as well as Btrfs and Bcachefs (and B Trees of course). What a wonderful unplanned deep dive.
Bcachefs sounds awesome
ZFS is really nice. I started experimenting with it when it was being introduced to FreeBSD, around 2007-2008, but only truly started using it last year, for two NASes (on Linux).
It's complex for a filesystem, but considering all it can do, that's not surprising.
ZFS is boss. I'm already using it for storage. Need to learn how to use it for
/.Not recommended for single-disk root partitions. This is a mistake I've made myself. Recovery tools are non-existant on ZFS so non-parity setups are inherently risky. If you have root setup on at least raidz1 with at least 2 disks you are fine.
Personally I wouldn't consider recovery as an option at all because it could easily be unavailable because the SSD failed. Instead, I tend to add a mirror drive and/or keep frequent backups where that's not possible. So from that perspective ZFS is equivalent to Ext4, which I currently use. I'd prefer ZFS over it for it's data verification, snapshotting and datasets features.
I've successfully recovered data from ext4 on a broken drive on one occasion. I agree it would have been better to have backups so lesson learned I suppose. Still if I'd been on ZFS root with no mirror I'd have been even more SOL
The ext4 driver can read ext2/ext3 partitions while supporting the 2038 time issue
The only change here is the driver loading the filesystem
Ext3 support is already only available through the ext4 driver
You will still be able to mount an ext2 file system with the kernel until ext4 support is removed. That is still going to be a long, long time.
Nice, can we just do the same with ext3 and ext4 now?