ext3 partition unmountable

Hi all

After umounting a removable ext3 partition from my work PC, and trying to remount it at home, I've run into the following error trying to mount it as both ext2 and ext3:

EXT2-fs: ide1(22,65): couldn't mount because of unsupported optional features (10000).
EXT3-fs: ide1(22,65): couldn't mount because of unsupported optional features (10000).

e2fsck is similarly unhelpful:
e2fsck: Filesystem has unsupported feature(s) while trying to open /dev/hdd1

The kernels on both machines have the same ext3 options enabled, and they're both 2.4.8-ac6.

This is the first time I've tried moving the drive like this - I assumed it would work flawlessly. However, ext3 doco seems a bit sparse under Documentation/, so I'm not quite sure about the recovery steps needed.

I'd appreciate your help on this one :) Please CC me in...

Regards,
Dewet

--
Dewet Diener [email protected] -o)
Systems Administrator iTouch Labs / \
Self-confessed geek and Linux fanatic _\_v

SYN! ..... SYN! ACK! ..... ACK!
The mating call of the internet

If I'm reading the files right it looks like:
#define EXT3_FEATURE_INCOMPAT_COMPRESSION 0x0001

Did you compress the file system?

Do a "tune2fs -l /dev/hdc" and see what features are set.

----- Original Message -----
From: "Dewet Diener" <[email protected]>
To: <[email protected]>
Sent: Friday, August 17, 2001 9:03 PM
Subject: ext3 partition unmountable

features (10000).

features (10000).

/dev/hdd1

Not knowingly, no. Is that a mount option? I'm mounting them the same on both sides, so its rather strange...

Heh, not much more useful:

# tune2fs -l /dev/hdd1
tune2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
tune2fs: Filesystem has unsupported feature(s) while trying to open /dev/hdd1
Couldn't find valid filesystem superblock.

I'll probably have to take the drive back, and see if it now mounts in the original system :-/

Dewet

Dewet Diener   [email protected]     -o)
Systems Administrator     iTouch Labs     / \
Self-confessed geek and Linux fanatic    _\_v

SYN! ..... SYN! ACK! ..... ACK!
The mating call of the internet

Hi Dewet.

The relevant mount option is to specify the ext3 rather than the ext2 file system, and the flag you refer to gets set if ANYBODY sets the "COMPRESS THIS FILE" flag on ANY file on that file system. As far as I can tell, nothing ever resets that flag, even if the last file that was compressed gets uncompressed.

I suggested a while back that fsck should check whether there are any compressed files on the filesystem, and reset that flag if not, but as far as I can tell, nothing was ever done to implement that suggestion.

You have an old version of tune2fs, and need to get the one that knows about ext3 or alternatively apply the patch that was distributed some time ago and recompile - I'm not sure which.

Stephen: What's the current status regarding tune2fs and ext3, I'm a tad out of date in this respect?

That might help...

Best wishes from Riley.

I doubt that ever happened - its pretty much a single-user system, and I can't say that I quite know *how* to set that flag in the first place :)

I'm running e2fsprogs-1.22 (which is later than the one specified from Documentation/Changes), so I kinda assumed everything was fine...

Dewet

Hi,

No, 1.22 tune2fs knows about the journaling flags.

As of 1.22, ext3 is fully supported by tune2fs.

Indeed, I'd like to see what that gives you.

One quick question: are either of the machines big-endian (HPPA, PPC etc)?

Cheers,
Stephen

Well, haven't had a chance to stick it in again, but after I repaired it with e2fsck off a backup superblock, I'm assuming it will work fine...

Nope, just plain PIII and AMD :)

Regards,
Dewet

Could you please run

	 od -A x -t x1 /dev/hdd1

and send the output?

For the superblock I get:

000400 c0 74 07 00 e2 e8 0e 00 d8 be 00 00 e1 8c 0e 00 000410 b5 74 07 00 00 00 00 00 02 00 00 00 02 00 00 00 000420 00 80 00 00 00 80 00 00 a0 3f 00 00 2f e9 7e 3b 000430 2f e9 7e 3b 01 00 16 00 53 ef 01 00 01 00 00 00 000440 1f e9 7e 3b 00 4e ed 00 00 00 00 00 01 00 00 00 000450 00 00 00 00 0b 00 00 00 80 00 00 00 04 00 00 00 000460 06 00 00 00 01 00 00 00 b9 d3 6c 59 2d cc 42 13 000470 91 84 d4 7b 60 d2 d9 50 00 00 00 00 00 00 00 00 000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The incompat features are at superblock offset 0x60. So here it's 0x00000006 - EXT3_FEATURE_INCOMPAT_FILETYPE and EXT3_FEATURE_INCOMPAT_RECOVER.

Somehow you seem to have set bit 16, which isn't defined. Not sure how to fix this without simply running a binary editor against /dev/hdd1 and clearing the byte at offset 0x462.

-

Here's mine:

000400 c0 5b 0e 81 de ab 1c 00 fe 6e 01 00 2c fa 13 00 000410 1d 36 0e 00 00 00 02 00 02 00 02 00 02 00 00 80 000420 00 80 00 80 00 80 00 20 60 3f 00 00 a3 56 7f 7f 000430 b6 56 7d 3b 0c 00 15 80 53 ef 00 00 01 00 01 81 000440 53 99 48 7b 00 4e ed 00 00 00 01 00 01 00 00 00 000450 00 00 08 00 0b 00 00 00 80 00 00 00 00 00 02 00 000460 02 00 01 00 01 00 e8 00 e8 00 3c 8f 15 e9 42 00 000470 a9 5c fe bf ec a6 84 ef 00 00 00 00 00 00 00 00 000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, mine's 0x00010002 - EXT3_FEATURE_INCOMPAT_FILETYPE, as well as the undefined bit?

I will certainly give that a try...

Dewet

Hi Andrew

I managed to fix it by running e2fsck off one of the backup superblocks - that seems to have repaired the broken bits:

000400 cc 5b 0e 00 de ab 1c 00 ff 6e 01 00 35 da 13 00 000410 1f 36 0e 00 00 00 00 00 02 00 00 00 02 00 00 00 000420 00 80 00 00 00 80 00 00 60 3f 00 00 df 05 7f 3b 000430 df 05 7f 3b 16 00 14 00 53 ef 01 00 01 00 00 00 000440 60 05 7f 3b ed 4e ed 00 00 00 00 00 01 00 00 00 000450 00 00 00 00 0b 00 00 00 80 00 00 00 04 00 00 00 000460 06 00 00 00 01 00 00 00 e8 08 28 0e 57 e9 42 00 000470 ff 7d fe 3d ec af 84 ef 00 00 00 00 00 00 00 00 000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then I just reran "tune2fs -j", and mounted it as ext3. I hope that was the correct approach, but its working in any case :) Don't quite know why/how the superblock got corrupted like that in the first place :-/

Regards,
Dewet

Andrew, for future reference, a much simpler way of debugging this sort of problem (which doesn't require interpreting od -x dumps) is to ask the user to use the command:

dumpe2fs -f -h /dev/hdd1

To clear the feature flag, you can use the debugfs program:

% debugfs

debugfs:  open -w -f /tmp/testfs
debugfs:  features   
Filesystem features: filetype FEATURE_I16 sparse_super
debugfs:  feature ^feature_i16
debugfs:  features
Filesystem features: filetype sparse_super
debugfs:  quit

Well, sounds like the in-core copy of the superblock got corrupted somehow, or perhaps a passing bit of cosmic radiation flipped the bit as it was getting written back to disk. If you can get it to do it repeatably it, or if it even happens once or twice more, we'd definitely want to know more about it.

- Ted