I would like to know about considerations for running an "old" e2fsck on a "new" filesystem. I have a general question and some specific ones.
. general -
Is it safe? always? sometimes? never? depends on which fs features and extensions are used?
safe provided -n specified but not otherwise?
Does e2fsck have some way of recognizing existence of some feature that it has not (in its present version) ever envisaged and also know whether attempting to repair a damaged newer fs with feature xxx will actually do more harm?
I note that dumpe2fs does not (as far as I can see) report the version of mke2fs used to create it, but does report optional features - but is the version stored anywhere in the fs? Is that itself relevant?
. specific -
I use a tiny linux-on-a-floppy (tomsrtbt) which has linux 2.2.20 kernel, libc.so.5, and e2fsck 1.27
Is it safe to run e2fsck in read-only (safe meaning will return correct information) and in read-write (safe meaning safe)
on, e.g., a filesystem that has the extended attributes feature in use.
If not safe, then does anyone know whether it is possible to build some newer, safe version of e2fsprogs against libc.so.5? I tried with 1.40.2 and it failed but maybe if I had tried harder it might have succeeded?
To put it another way, given that 1.27 builds on libc.so.5 and runs on kernel 2.2, does anyone know which was the first (earliest) version of e2fsprogs that pre-reqs libc.so.6 and/or kernel 2.4?
You are treading dangerous waters. You can safely run e2fsck -n on a newer FS, but I would not attempt it in write-able mode. I believe e2fsck does look at some of the "capabilities" flags in the superblock and may even complain about the ones it doesn't recognize. I don't remember specifically what the source code does and how judicious it is in trying to prevent you from doing something stupid.
Over the years features like hashed directories, ACLs, journaling, etc. have been added to become the modern-day ext3. Older fsck doesn't understand any of that, and could likely do harm. Don't ask me for a version-specific timeline 'cuz I certainly don't know that, but you can figure that out from e2fsck-progs historical record (i.e. release notes).
As far as building the latest e2fsck-progs against your version of libc: I think it should be possible. I don't know about 1.40 on 2.2 kernels, but I've built 1.38 on 2.4 kernels. So you may find perhaps not the latest, but a more modern version than your 1.27 that builds easily on 2.2
No, it's not dangerous at all. It may not *work*, but if your filesystem has features enabled that e2fsck doesn't recognize, it will simply refuse to touch your filesystem. It will complain that it doesn't know how to handle a specific filesystem feature, and just bail out. We've been very careful not to add any extensions without also adding a new filesystem feature compatibility bitmask. In fact, Linux has a very complicated scheme which allows us to tag a particular feature as "safe for the kernel to touch read/only, but not read/write and not by e2fsck", "safe for the kernel to touch read/write, and for e2fsck", and "not compatible at all if you don't know what the feature flag means". So it's always safe to try using an old e2fsck against a newer filesystem. It will most likely not work, as it fails with an error message, but it is safe to try.
In terms of building the latest e2fsprogs against an older kernel/glibc combination, it should work. E2fsprogs is very portable, and will build on a wide variety of platforms, including Solaris, BSD, MacOS, and using a variety of libc's. In fact, for the Debian version of e2fsprogs 1.40.4, I built a statically linked version of e2fsck against dietlibc that will work on a Linux 2.4 (and probably a Linux 2.2) kernel.
IMHO there are 2 issues: new features and old bugs. I'll take it on faith that older fsck is careful not to touch a filesystem if it sees unknown new features. But what about bugs? Surely many bugs only come to light when fsck is tested against newer filesystems, right? So if an older fsck decides that a given FS is within compatibility range based on features, then the newer FS may fall victim to old fsck bugs.
For example, I seem to remember a bug whereby fsck gratuitously limited the size of a directory to 32 Mbytes, and if it found one larger than that, it would consider it corrupt and attempt to "repair" it. So if an older fsck with this bug is executed against a newer FS with a very large directory, then you better hope that the feature incompatibility guard saves your bacon.
It's all moot of course, since johnlumby managed to build the latest e2fsprogs on his floppy kernel.
Sure, but what you are describing is not forward compatibility problem, but just a truism; if a bug is fixed in version 1,37, and you are using 1.34, then you will still be affected by that bug. Most of the time, the bugs that turn up have nothing to do with specific feature compatibility flags, but just with various edge conditions that don't come up all that often. In order the cases the bug might be caused by new code that was introduced (for example) in 1.36, and then fixed in 1.37. So sometimes a new version of e2fsprogs might have some new bugs, too!
This is true in any package, although like in all other packages, I try to make each release less buggy than the last, instead of the other way around. But for example, since there will be many more new features in 1.41, when it gets released, it will probably have more bugs than 1.40.4. Hopefully most of them will only affect people trying to use the newer ext4 filesystem features, and I do have a regression test suite, which I run before I commit any changes to the source tree, but things are never 100% perfect.
So in that sense, I do recommend that people run the latest version of e2fsprogs whenever possible. However, that being said, it's not like a specific version of e2fsprogs, say 1.34 gets any worse over time, or gets *more* dangerous to use. It's just that newer versions of e2fsprogs are safer. (And in general e2fsprogs is **very** paranoid about not losing data, or making things worse.)
Many thanks indeed for that information. Good to know about the safety capabilities!
Encouraged by your remarks about portability, I tried building the current 1.40.4 in my libc.so.5 and linux 2.2.20 environment again and with just a few patches here and there I got it to compile and link just fine and based on a few tests it is working ok on the tomsrtbt system. That has made this floppy-linux system potentially quite a lot more useful to me. (I use it for emergency repair).
I guess it is unlikely anyone else will want those patches but if anyone does, just let me know.
Can you post the patches to e2fsprogs's SF "patches" tracker? I'll take a look at them.
In general I do like to make e2fsprogs as portable as possible, so if patches are needed to make it compile on an older Linux systems, as long as they aren't _too_ ugly and compromise portability, or would break portability on other systems, I'll certainly consider applying them.
posted as request number 1865843
but more for interest - I doubt you would want to incorporate them as they remove some minor functionality
(such as the test for a process PR_DUMPABLE flag) and other things. I did not make any attempt to make them
generic for other environments.
Thanks! It won't be that hard to fix some of them to be portable patches. I assume for example the reaosn why you had to comment out the PR_DUMPABLE chunks was because 2.2 didn't implement the prctl system call, or didnt implement PR_GET_DUMPABLE. So if it's just a matter of checking for ENOSYS, or the appropriate errno value, that wouldn't be hard to get that patched it.
Looks also like libc5 didn't have strtoull; I suppose an #ifdef HAVE_STRTOULL with the appropriate configure.in test added would solve that issue, perhaps with a #warning that really arguments won't be accepted.
Re PR_DUMPABLE - that's right, my linux 2.2 has prctl but prctl doesn't have the PR_DUMPABLE options.
And libc5 didn't have strtoull.
Re the missing pwrite and pread - they are in my 2.2 kernel but not exported from my libc5. I suspect the libc5 may be older than the kernel.
I compiled the code with egcs-2.91.66 against the libc5 libraries and headers and 2.2.20 kernel headers. I did so while actually running under a current libc6 and 2.6 kernel but I believe that (runtime environment) is irrelevant.