[HN Gopher] Linux ext2 filesystem driver now marked as deprecated
___________________________________________________________________
Linux ext2 filesystem driver now marked as deprecated
Author : rrampage
Score : 150 points
Date : 2024-03-28 06:13 UTC (2 days ago)
(HTM) web link (bootlin.com)
(TXT) w3m dump (bootlin.com)
| infamouscow wrote:
| From a code standpoint, this has been more or less the case for a
| few years.
|
| The ext4 driver is fully compatible with ext2.
| voltaireodactyl wrote:
| By any chance does that include interoperability with the ext2
| implementation used on theater projectors? Not a gotcha, if
| that's been solved that would make my life tremendously easier.
| happymellon wrote:
| Do they not follow the normal ext2 implementation?
| jchw wrote:
| As far as I know literally all you have to do is mount with
| -t ext4 (which presumably will just happen by default for
| ext2 superblocks after this.) As far as I know, it will
| definitely not automatically enable ext2/ext3-incompatible
| features, you have to do this manually (though doing so is
| relatively easy.)
| chungy wrote:
| the ext4 driver doesn't (in fact, cannot) upgrade file
| systems missing features. If you mount an ext2 file system
| from the 1990s with the ext4 driver, it'll stay at the old
| feature set, for better and worse.
|
| You can use tune2fs to upgrade file systems, downgrading is
| not (usually) possible without a full backup and restore.
| loeg wrote:
| Possibly decades. The ext3 driver, which the ext4 driver is a
| fork of, could also mount ext2 filesystems.
| krallja wrote:
| It's been a long time since I've used either, but ext3 _is_
| ext2, with journaling added on top, right?
| bombcar wrote:
| If I recall correctly the journal was stored in a dot file
| or similar that could only be seen when loaded as ext2.
| loeg wrote:
| Yeah, and ext4 is ext3 with some extra features.
| chungy wrote:
| Basically they're all ext2 with different implied feature
| flags enabled.
| jasoneckert wrote:
| Now hopefully we'll get a new version of mkfs that doesn't use
| ext2 by default when a filesystem type is not specified.
| spiesd wrote:
| This is completely orthogonal, and not particularly relevant.
| That said, I didn't know this was the case. In fact, I'd assume
| an unspecified mkfs would complain these days.
|
| 1) mkfs is a userspace utility. Its defaults have no
| consideration for which kernel driver implements this
| interface; I'd bet a dollar that mkfs has been hitting the ext4
| driver for ages. 2) As stated in sister comments, support for
| actual ext2 filesystems is unaffected. 3) Using a very simple
| fs by default seems like a good thing. FAT (variants) has
| survived forever by being dirt-simple, despite its faults. 4)
| Who in the world doesn't specify options to mkfs? It's one of
| the few operations that really doesn't have "sane defaults".
|
| Is there a "better" default fs? I dunno. I've looked at a few,
| but most seem... troubled. So many trade-offs.
| loeg wrote:
| If there is going to be a default, it is inarguably more
| reasonable to pick ext4 than ext2.
| spiesd wrote:
| Huh. I hadn't checked it, but plain mkfs does create ext2.
| Interesting. I agree, ext4 seems a sensible baseline today.
| nailer wrote:
| This is a lot of words but yes anything that's not deprecated
| is an obvious sensible default.
| dwheeler wrote:
| As I understand it, the ext2 _format_ isn 't deprecated.
| The original driver that ONLY supports ext2 is deprecated.
|
| However, the ext4 driver also supports the ext2 format, and
| there are no plans to deprecate the ext4 driver.
| arp242 wrote:
| mkfs(8):
|
| > This mkfs frontend is deprecated in favour of filesystem
| specific mkfs.<type> utils.
| ch33zer wrote:
| For anyone looking to learn a bit more about filesystems ext2
| strikes a great balance of simplicity and real world
| practicality, making it good to learn from. Code here
| https://elixir.bootlin.com/linux/v3.9/source/fs/ext2
| gertop wrote:
| Seems to me like either exFat or FAT32 would be simpler?
| There's billions of devices using it with millions more sold
| every year, and it's supported by all operating systems in
| current use so it also has greater real world practicality.
| userbinator wrote:
| FAT is definitely far more portable; exFAT, not so much.
| bbatha wrote:
| exFAT is pretty portable these days and not encumbered by
| annoying file and disk size limitations. Its the default
| for SD cards and has had native support in Macos and
| windows for 15 years, linux has had kernel drivers for 5
| years and FUSE/3rd party kernel modules for longer. Unless
| you need to interface with an ancient system there's no
| reason to use FAT on portable drives anymore.
| G3rn0ti wrote:
| I had trouble booting the Windows 10 installer from an
| exFAT formatted usb drive. That was thee years ago. So
| back then I had to recompress a cab file to make it
| smaller than 4GB using Linux. It worked but I was
| scratching my head that this was an issue.
| opan wrote:
| I thought Windows install drives used NTFS.
| G3rn0ti wrote:
| I guess this could work but all instructions I could find
| back then were saying to create a FAT32 file system. I
| switched to exFAT after finding some installation files
| being large than 4GB. But then the stupid thing would not
| boot. So I managed to re-compress the largest cab file
| and got it below 4GB.
|
| Edit:
|
| But I am not sure an NTFS formatted stick is actually
| UEFI-bootable.
| userbinator wrote:
| UEFI is only specified to boot from FAT32, but apparently
| some BIOSes have included an NTFS driver:
|
| https://superuser.com/questions/588080/uefi-boot-a-ntfs-
| driv...
|
| https://superuser.com/questions/1234496/windows-10-efi-
| folde...
|
| The other notable exception I knew of from before was
| Apple's UEFI had HFS+ support (and loads the boot file
| from its own nonstandard location.)
| justsomehnguy wrote:
| > But I am not sure an NTFS formatted stick is actually
| UEFI-bootable.
|
| Practically - no.
|
| But you can make a FAT32 standard bootable thumb drive,
| without install.wim which is > 4GB, make a second
| partition on that drive and format it NTFS, place
| everything (including install.wim) there and launch it
| from there after WinPE would run from the first
| partition.
| deknos wrote:
| but it's encumbered by patents of microsoft. BSDs or
| Reactos or minix are not allowed to implement it and
| distribute it freely.
|
| only linux got a free pass from microsoft as they use it.
|
| F** Microsoft and EXFat as long it's not freely
| implementable and distributable with free or open
| software.
| fragmede wrote:
| https://www.micski.dk/2021/04/10/how-to-mount-exfat-
| formatte...
|
| makes no mention of distribution issues. can you
| elaborate?
| lexlash wrote:
| Your link discusses how to install fusefs-exfat, which is
| a separate package, which is what all Linux distributions
| did before the 2019 licensing - Android had a separate
| licensed kernel module, etc. I can't speak to the current
| state of BSD but a cursory search yields a lot of
| discussion.
|
| Regarding the encumbrances in general,
| https://en.wikipedia.org/wiki/ExFAT covers this, notably:
|
| > Companies can integrate exFAT into a specific group of
| consumer devices, including cameras, camcorders, and
| digital photo frames for a flat fee. Mobile phones, PCs,
| and networks have a different volume pricing model.
|
| > exFAT is the official file system of SDXC cards.
| Because of this, any device not supporting exFAT, such as
| the Nintendo 3DS, may not legally advertise itself as
| SDXC compatible, despite supporting SDXC cards as mass
| storage devices by formatting the card with FAT32 or a
| proprietary file system tied to the device in question.
|
| > On 28 August 2019, Microsoft published the exFAT
| specification and released the patent to the Open
| Invention Network members. The Linux kernel introduced
| native exFAT support with the 5.4 release in November
| 2019.
|
| So yes, this has been annoying for years (2006-2019, at a
| minimum) and left a very bad taste in my mouth as someone
| who has a few dozen SD cards that regularly move around
| various embedded devices that are expensive, rarely
| receive updates, and work just fine (e.g. 3d printers,
| digital frames, regular printers, local storage on
| security cameras, adapters for retro hardware, etc.). The
| Wikipedia article notes that the Nintendo 3DS - 75.94
| million units sold during its 2011-2019 lifespan [1] -
| lacked exFAT support, so it's not like this only affected
| low-end/cheap/uncommon devices from small companies.
|
| Windows "helpfully" disabled all ways to format large SD
| cards as FAT32 so I end up having to rely on a third
| party tool.
|
| Of course, whenever possible, I use a sane and journaled
| filesystem but it's rare that I have a choice. :)
|
| [1] Numbers sourced from
| https://en.wikipedia.org/wiki/Nintendo_3DS
| deknos wrote:
| This. and the BSDs or Minix are not in the "Open
| Invention Network" and as far as i can see, the BSDs
| still do not have a kernel extfat implementation as i far
| as i just have checked on their websites
| NavinF wrote:
| Those filesystems also don't trust their input and check
| bounds correctly. Mounting a malicious ext* partition can
| trigger code execution so it's never auto mounted and
| shouldn't be used on removable drives. This is a really weird
| limitation that the other common file systems don't have
| chungy wrote:
| Not sure what system you've used, but I've never seen
| automounting fail to work on ext4 volumes.
|
| That being said, basically every file system ever is
| vulnerable to the malicious image. Kernel drivers assume
| that the metadata is sane enough and mistakes are from
| simple bugs, not deliberate attacks.
| JackSlateur wrote:
| This is true for virtually all filesystems
|
| From the kernel point of view, the filesystem code runs in
| kernel mode and expects a trusted block device
|
| Some people (from gnome etc) do auto-mount filesystems,
| which is a crazy idea and they know it but they do not care
|
| https://lwn.net/Articles/951846/
| Zambyte wrote:
| Maybe GNOME is just designed with great anticipation for
| GNU Hurd :-D
| uuddlrlrbaba wrote:
| Considering auto mount is now built into systemd I'd say
| its not such a crazy idea after all
| ploxiln wrote:
| Haha - there are many graybeards who would call most of
| systemd kinda crazy (myself included). But let's not get
| derailed into the old systemd debate here :)
| JackSlateur wrote:
| Exposing your users to a known (and easily exploited)
| vulnerability is a sick behavior, regardless of what you
| think of the authors of said behavior.
| Dwedit wrote:
| FAT16/FAT32 is what you use when you want all your files to
| suddenly become 32768 bytes large instead of their actual
| file size (true story).
|
| More specifically, the cluster chain got overwritten with
| junk data, so all files got truncated down to one cluster in
| length.
|
| This is why metadata Journalling exists for file systems.
| indigodaddy wrote:
| I remember even into the early 2010s we would still just make for
| example /boot ext2 for simplicity sake (perhaps?). Is that still
| in practice? Haven't been in the OS deployment weeds for a
| minute..
| sargun wrote:
| And to avoid wasting space on the journal. Also, iirc
| bootloaders didn't have full ext3 support yet.
| Latty wrote:
| People tend to use FAT these days because it tends to be an EFI
| system partition and almost all modern systems are UEFI.
| ssl-3 wrote:
| And eons ago, people made fun of me for using MS-DOS and
| loadlin as a bootloader for Linux. (This always worked fine
| for me, and MS-DOS was simple to make boot and install tools
| on with hardware of the time. A functional-enough MS-DOS
| installation took up a trivial amount of space on a garden-
| variety PC of the day, and it was easy to pare down.)
|
| Fast forward 20 or 30 years: We're back to using a FAT[32]
| partition for booting, just with a very different mini-OS to
| do the job.
|
| le sigh.
| BirAdam wrote:
| I dunno that it's really all that different. EFI is sort of
| what DOS would likely have become if MS had kept with it.
| It uses PE format, has back slash paths, has the same .3
| extensions, and so on. There are certainly many
| similarities.
| ssl-3 wrote:
| What's different is that using loadlin on MS-DOS was
| "lol, fuckin' newb" material (even though it was
| exquisitely functional and ridiculously easy to use),
| while the potentially very similar EFI system is a
| heralded as a champion.
|
| I guess I am trying to express my annoyance with the
| Linux crowd's fickle nature over the years.
| LeoPanthera wrote:
| I use ext4 (for /boot) but I always enable "sync". I always
| imagine that makes it less likely to suffer corruption but I
| have no actual evidence for that. I might be making it up.
| perihelions wrote:
| It's the default for Debian,
|
| - _" The default file system selected in most cases is ext4;
| for /boot partitions ext2 will be selected by default when
| guided partitioning is used."_
|
| https://www.debian.org/releases/bookworm/amd64/ch06s03.en.ht...
| ( _" Debian GNU/Linux Installation Guide (Bookworm/amd64)_")
| userbinator wrote:
| I'm not very familiar with Linux filesystem drivers, but it seems
| odd that there's separate ext2, presumably ext3, and ext4 drivers
| when the latter are (100%?) backwards-compatible with the former
| filesystems.
| derbOac wrote:
| At one time at least, you'd hear arguments for sticking to ext2
| (and then ext3) for stability reasons.
|
| But I think your question is why they're being deprecated now.
| yjftsjthsd-h wrote:
| IIRC ext3 _was_ folded into the ext4 driver. If I was guessing,
| I would say that they preserved ext2 separately this long
| because it 's a much simpler chunk of code to maintain. (And
| it's simple, known, stable code, while ext4 continues to
| undergo active feature development. Not sure how likely that
| angle is.)
| t0mas88 wrote:
| I haven't checked, but I expect the ext2 driver to be smaller.
| Which can be relevant for embedded systems with limited flash
| space.
| cesarb wrote:
| That happened because the code changes from ext2 to ext3, and
| later from ext3 to ext4, were very invasive, and filesystems is
| one place where stability and reliability is very important. So
| instead of risking introducing data-loss bugs, they forked the
| code. It was always the plan that the older code would be
| removed some time later, once the newer code had proven its
| stability for a while.
|
| The on-disk format for these three is the same; the difference
| is that the later ones understand more of the "incompatible"
| additions to the on-disk format (IIRC, the main ones being the
| journal for ext3, and extents for ext4, but there are others).
| You can convert an "ext2" filesystem into an "ext4" one by just
| enabling the relevant filesystem format flags on the
| superblock, and making a few necessary adjustments (for
| instance, creating a journal when enabling the "has journal"
| flag).
| m463 wrote:
| I wonder if they will rename all the *2* utilities
|
| (e2fsck, resize2fs, etc)
| ilvez wrote:
| I guess not, since ext2 fs is going nowhere, still viable
| filesystem that is supported through ext4 driver.
| dredmorbius wrote:
| Script compatibility is another factor.
|
| e2fsprogs is already comprehensive of 2, 3, and 4 versions:
| <https://sourceforge.net/projects/e2fsprogs/>
| pjmlp wrote:
| I still remember when it was brand new and only advised for those
| willing to take a risk with their data.
| NelsonMinar wrote:
| I really appreciate all this slow but inevitable work to solving
| the 2038 problem. In the wake of Y2K when we first talked about
| 2038 it was a joke, "ah we'll all be retired then and anyway
| computers will be totally different". But here we are now, 24
| years later and 14 years before the actual deadline. Thankfully
| folks are doing the work of fixing the deeper system limitations.
|
| I'm retired now but fully expecting to dust off a bunch of Unix
| skills in late 2037, early 2038. I suspect by then many people
| who know how to, say, build a Linux kernel from the command line
| will either be dead, retired, or too busy doing more fun things.
| omoikane wrote:
| Related, list of filesystems and their rollover dates:
|
| https://github.com/y2038/y2038-list?tab=readme-ov-file#file-...
|
| Note that the earliest date on the list is 2028 with isofs (used
| on CDs).
| jezze wrote:
| I don't understand the immediate concern about using 32 bits for
| file creation and modification times. Its reasonable to assume
| that if the value has overflown and is very low that its not
| indicating a date from 1970. There is probably room to add a
| single bit indicating if the epoch is 1970 or 2038.
| kardos wrote:
| That amounts to changing it to a 33 bit time stamp
___________________________________________________________________
(page generated 2024-03-30 23:02 UTC)