7 ms·

Linux ext2 filesystem driver now marked as deprecated

163 points by rrampage 3y ago

infamouscow 3y ago
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 3y ago
  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 3y ago
    Do they not follow the normal ext2 implementation?
  - jchw 3y ago
    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 3y ago
      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 3y ago
  Possibly decades. The ext3 driver, which the ext4 driver is a fork of, could also mount ext2 filesystems.
  - krallja 3y ago
    It’s been a long time since I’ve used either, but ext3 _is_ ext2, with journaling added on top, right?
    - bombcar 3y ago
      If I recall correctly the journal was stored in a dot file or similar that could only be seen when loaded as ext2.
    - loeg 3y ago
      Yeah, and ext4 is ext3 with some extra features.
      - chungy 3y ago
        Basically they're all ext2 with different implied feature flags enabled.
jasoneckert 3y ago
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 3y ago
  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 3y ago
    If there is going to be a default, it is inarguably more reasonable to pick ext4 than ext2.
    - spiesd 3y ago
      Huh. I hadn't checked it, but plain mkfs does create ext2. Interesting. I agree, ext4 seems a sensible baseline today.
  - nailer 3y ago
    This is a lot of words but yes anything that’s not deprecated is an obvious sensible default.
    - dwheeler 3y ago
      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.
sour-taste 3y ago
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 https://elixir.bootlin.com/linux/v3.9/source/fs/ext2
- gertop 3y ago
  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 3y ago
    FAT is definitely far more portable; exFAT, not so much.
    - deleted 3y ago
      [deleted]
    - bbatha 3y ago
      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 3y ago
        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.
        3y ago
indigodaddy 3y ago
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 3y ago
  And to avoid wasting space on the journal. Also, iirc bootloaders didn’t have full ext3 support yet.
- Latty 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        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.
userbinator 3y ago
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 3y ago
  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 3y ago
  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.)
- deleted 3y ago
  [deleted]
- t0mas88 3y ago
  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 3y ago
  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 3y ago
I wonder if they will rename all the *2* utilities (e2fsck, resize2fs, etc)
- ilvez 3y ago
  I guess not, since ext2 fs is going nowhere, still viable filesystem that is supported through ext4 driver.
  - dredmorbius 3y ago
    Script compatibility is another factor. e2fsprogs is already comprehensive of 2, 3, and 4 versions: <https://sourceforge.net/projects/e2fsprogs/ https://sourceforge.net/projects/e2fsprogs/>
pjmlp 3y ago
I still remember when it was brand new and only advised for those willing to take a risk with their data.
NelsonMinar 3y ago
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 3y ago
Related, list of filesystems and their rollover dates: https://github.com/y2038/y2038-list?tab=readme-ov-file#file-systems 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 3y ago
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 3y ago
  That amounts to changing it to a 33 bit time stamp
- darby_eight 3y ago
  [dead]

163 points by rrampage 3y ago

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 3y ago
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 3y ago
  Do they not follow the normal ext2 implementation?
- jchw 3y ago
  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 3y ago
    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 3y ago
Possibly decades. The ext3 driver, which the ext4 driver is a fork of, could also mount ext2 filesystems.
- krallja 3y ago
  It’s been a long time since I’ve used either, but ext3 _is_ ext2, with journaling added on top, right?
  - bombcar 3y ago
    If I recall correctly the journal was stored in a dot file or similar that could only be seen when loaded as ext2.
  - loeg 3y ago
    Yeah, and ext4 is ext3 with some extra features.
    - chungy 3y ago
      Basically they're all ext2 with different implied feature flags enabled.

jasoneckert 3y ago

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 3y ago
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 3y ago
  If there is going to be a default, it is inarguably more reasonable to pick ext4 than ext2.
  - spiesd 3y ago
    Huh. I hadn't checked it, but plain mkfs does create ext2. Interesting. I agree, ext4 seems a sensible baseline today.
- nailer 3y ago
  This is a lot of words but yes anything that’s not deprecated is an obvious sensible default.
  - dwheeler 3y ago
    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.

sour-taste 3y ago

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 https://elixir.bootlin.com/linux/v3.9/source/fs/ext2

gertop 3y ago
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 3y ago
  FAT is definitely far more portable; exFAT, not so much.
  - deleted 3y ago
    [deleted]
  - bbatha 3y ago
    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 3y ago
      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.
      - 3y ago

indigodaddy 3y ago

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 3y ago
And to avoid wasting space on the journal. Also, iirc bootloaders didn’t have full ext3 support yet.
Latty 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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.

userbinator 3y ago

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 3y ago
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 3y ago
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.)
deleted 3y ago
[deleted]
t0mas88 3y ago
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 3y ago
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 3y ago

I wonder if they will rename all the *2* utilities (e2fsck, resize2fs, etc)

ilvez 3y ago
I guess not, since ext2 fs is going nowhere, still viable filesystem that is supported through ext4 driver.
- dredmorbius 3y ago
  Script compatibility is another factor. e2fsprogs is already comprehensive of 2, 3, and 4 versions: <https://sourceforge.net/projects/e2fsprogs/ https://sourceforge.net/projects/e2fsprogs/>

pjmlp 3y ago

I still remember when it was brand new and only advised for those willing to take a risk with their data.

NelsonMinar 3y ago

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 3y ago

Related, list of filesystems and their rollover dates: https://github.com/y2038/y2038-list?tab=readme-ov-file#file-systems 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 3y ago

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 3y ago
That amounts to changing it to a 33 bit time stamp
darby_eight 3y ago
[dead]