Linux 6.9 Deprecates The EXT2 File-System Driver

[NovenTheHero]

I don't really understand why people like having so many mount points tbh.

Even partitions are mostly useless (apart from the EFI FAT32 crap and requirements). If you want a separate filesystem (which is totally understandable, such as not polluting the metadata/inodes on the other one) you can just use a loopback mount on an image file containing it.

And it won't even take permanent space if it's not full, just call fstrim on it and it automatically shrinks. There's your "partition" as a simple file on your main partition.

Probably just habit from years and years ago. These days I just stick with the /boot/efi and / with /home on a separate drive.

[carewolf]

I don't really understand why people like having so many mount points tbh.

It no longer makes sense. It made sense historically. You had one drive rarely written to boot from. Often using a simple FS that the bootloader could understand (there was a time long ago when grub didn't understand ext4).

Similarly with the separation between / and /usr, all due to ancient history.

[emblemparade]

It did, but apparently some people didn't read properly:

Right. But my point is that Phoronix put that very important point as the last sentence of the article. It should have been more prominent. That's what I meant by "properly".

I hate to raise this point, but I think Phoronix does this frequently: make a non-controversial issue into a controversial one by subtly sensationalizing it. I guess it generates clicks.

[Old Grouch]

Huh? As far as I know, they are FAT formatted. The only difference is that they have the "EFI System" partition type instead of "Microsoft basic data" in the partition table.

You do not know far enough. That is not the only difference.

[Old Grouch]

https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1

> EFI encompasses the use of FAT32 for a system partition, [...] The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system.

Please share references to back up your claims next time.

Your reference: 13.3.1.2. File Names

Note: Although the FAT32 specification allows file names to be encoded using UTF-16, this specification only recognizes the UCS-2 subset for the purposes of sorting or collation.

Yes, it is minor. But it is a difference that will catch people out.

[Old Grouch]

Care to provide a link to such differences?

Done. See later in this thread.

[NateHubbard]

You don't need to have your whole /boot in the crappy FAT format.

Well, my /boot partition only has the EFI folder, so I'd say that's not always correct.

[reavertm]

I don't really understand why people like having so many mount points tbh.

Even partitions are mostly useless (apart from the EFI FAT32 crap and requirements). If you want a separate filesystem (which is totally understandable, such as not polluting the metadata/inodes on the other one) you can just use a loopback mount on an image file containing it.

And it won't even take permanent space if it's not full, just call fstrim on it and it automatically shrinks. There's your "partition" as a simple file on your main partition.

You answered it yourself - EFI FAT32 crap. It doesn't support symlinks. Symlinks become useful when dealing with grub (grub.conf) and how it's by default configured in distributions.
If you have LUKS-encrypted rootfs, you need to have either EFI-stub kernel on EFS or kernel+initrams (with cryptsetup and actual root fs filesystem support) there and bootloader that can boot Linux.
Many distributions haven't figured out EFI-stub yet and for legacy reasons configure grub.conf to be installed to /boot/grub/grub.cfg, but under EFI, grub expects grub.conf on EFS.
Most distributions haven't figured out (or don't care) how to achieve it all on EFS only, safely, in package backward compatible manner (support legacy and UEFI) it seems because for encrypted rootfs setup they by default just create EFS and separate boot partition and are done with it.
/boot/efi is usually mount point of EFS, /boot cannot be made EFS with 'efi' being symlink to '.' so that grub-install and grub-mkconfig works on it out of the box.

Sure, if you know what you are doing, separate /boot partition is not necessary.

I agree with someone else here that /boot btrfs sub-volume is rather odd choice. /boot is supposed to be easily accessible by the bootloader..

Loopback idea.. you still need to store that image file somewhere.. If one needs flexibility, sure. If not, partition table + fstab is more suitable to store partition metadata than root filesystem + custom scripts.

[uxmkt]

Even partitions are mostly useless [...] If you want a separate filesystem [...] you can just use a loopback mount on an image file containing it.
And it won't even take permanent space if it's not full, just call fstrim on it and it automatically shrinks. There's your "partition" as a simple file on your main partition.

Moreover, you don't even need btrfs to get snapshots, just use `cp --reflink` on that (trimmed) image file.

[toves]

Seemingly ext2 deprecation pretty much resolves to what /boot is formatted as which in turn determined by what grub2 supports (in thel x86 world.) Non x86 systems not using grub2 probably have different limitations.
From memory ext2 is pretty simple and mostly variation on the original bsd file system so I guess it would fairly easy for an embedded developer to maintain their own an out of tree kernel module.
I quite liked the system V boot filesystem (bfs) even simpler than fat and barely a step up from a list logical blocks which firmware could easily grok. I think it was intended to for the /stand (~ /boot) which held the kernel components. At the time seemed a bit better than the PC's x86 bios dumping the boot disk's first sector into memory at a fixed location.