Bug 156954

Created attachment 114062 [details]
output of fsck, fsck again and then dumpe2fs

This shows fsck being run twice in succession and failing to fix the problem
(without any indication it failed to fix the problem either), and then the
output of dumpe2fs.

Following the advice on:

http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.36

to clear the resize_inode feature from the superblock, has fixed the problem and
allowed the fs to fsck clean consistently. 

If this was a known problem to Ted T. several months ago, with a known fix - how
come FC4dev still has this problem? Seems fairly serious to me. Particularly as
resize2fs has been quite stable for several years now, so as a user I've built
up confidence in it working reliably. It appears part of the problem (from my
quick and limited research) is the addition of 'ext2online' patches to resize2fs
- which completely violates the trust built up by users in the robustness of
this programme. So my questions is:

- Why was it decided to destabilise resize2fs? 

My understanding is that ext2online normally is a seperate utility, if the new
functionality is known immature or incompatible with resize2fs, why try
aggregrate it into resize2fs? Leaving them seperate would leave users the choice
of sticking with the mature offline resize2fs.

- If these incompatibilities have been known about for at least several months,
and dating back to an older upstream version of e2fsprogs, why does FC4dev still
at this late stage have the broken patches included?

I don't mean to get upset, but this is playing fast and loose with users' data.
I'm glad I discovered this on just a test box..

regards,

Paul Jakma.

This was a known problem several months ago, the fix was in 1.36, and we ship
that in fc4t2.  Evidently you are not seeing the same problem.

> - If these incompatibilities have been known about for at least several 
> months, and dating back to an older upstream version of e2fsprogs, why 
> does FC4dev still at this late stage have the broken patches included?

It does not.  We ship the upstream e2fsprogs-1.37 resize2fs, without extra
patches: online resize support is already in upstream e2fsprogs.  As far as we
know, it is fully compatible with the online resize.  

But clearly you are seeing a problem that we haven't seen before, and that has
not shown up in our testing.  It would be helpful if you could describe what you
did prior to the problem occurring, so that we can reproduce and fix it. 
Specifically, the exact size that the filesystem was (as accurately as you can
remember), and how it was initially created (on which version of e2fsprogs),
would help us to recreate these conditions.

Hi Stephen,

Sorry for being over-dramatic. Good to hear it was fixed.

Further, I didn't install this machine, my hosting provider did and they had
installed FC3. I upgraded it to FC4dev. The FS which had the problem therefore
was created by stock FC3. I can't remember whether I resize2fs'd it with FC3 (i
dont think so, but i might have).

I actually can't replicate this with a filesystem mkfs'd and resize2fs'd with
the FC4dev provided versions of the tools. Apologies, seems like it was an
FC3/FC4dev cross-polination bug rather than a pure FC4dev.

However, it still leaves the issue of FC4dev fsck not being able to deal with
the presence of an invalid resize_inode created by FC3 tools. It offers the
option of 'recreate resize_inode? y/n' and neither option fixes the problem, and
leaves one with an unmountable fs. (in my case it was /usr - box couldnt boot
fully).

The attached files are the only information I have now on the problem, unless
you could use further information from the now fixed fs.

I had have this problem on my RHEL WS4 (kernel 2.6.9-11.EL)
I had run this one(found in the release notes of E2fsprogs 1.36 (February 5, 2005):
 debugfs -w /dev/hdXXX -R "features ^resize_inode"
 e2fsck -f /dev/hdXXX
Then I can clean boot my WS4.

I had NEVER run resise2fs or another resize programm on my system.

Fixed in rawhide.