Bug 139538 - ext3 online resize fails on bigendian hosts
Summary: ext3 online resize fails on bigendian hosts
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs   
(Show other bugs)
Version: 4.0
Hardware: powerpc Linux
Target Milestone: ---
: ---
Assignee: Stephen Tweedie
QA Contact: David Lawrence
Depends On: 135947
Blocks: 135876
TreeView+ depends on / blocked
Reported: 2004-11-16 16:40 UTC by Stephen Tweedie
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-10 22:13:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stephen Tweedie 2004-11-16 16:40:48 UTC
Build Identifier: 

The ext2/ext3 online resize tool does not perform appropriate byteswapping when
running on a bigendian host.  mke2fs and e2fsck correctly deal with it, and the
actual resize activity is in-kernel and should be byte-order safe, but the
ext2online tool does not.  As a result, when it tries to resize, it fails its
initial sanity checks on the device.

Reproducible: Always
Steps to Reproduce:
1. mke2fs ext3 filesystem
2. mount it
3. run ext2online

Actual Results:  
Example failure:

# ext2online /mnt/test
ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b
ext2online: ext2_open: invalid superblock
ext2online: can't open /dev/mapper/test-ext3

tested with e2fsprogs-1.35-11.3 (which contains the bigendian mke2fs fixes for
the online resize inode.)

Comment 1 Stephen Tweedie 2004-11-19 11:59:33 UTC
I've got the ext2online bits fixed up.  It now successfully performs online
resize, but after unmounting leaves the filesystem in an inconsistent state, so
there appear to be bugs remaining in the in-kernel portion of the resize on
bigendian hosts.

Comment 4 Stephen Tweedie 2004-11-19 23:18:37 UTC
Note on checking in fixes for this issue --- I've fixed a number of byte-order
problems in the userland tool, to the point where it appears to be running
correctly.  But until I have the entire userland + kernel toolset working
perfectly for bigendian hosts, I will not be checking in any of these fixes to

For now, it's far better for ext2online to complain immedately that it cannot
find  the filesystem superblock (due to byteswapped magic numbers) than for it
to proceed but then invoke buggy kernel code and potentially corrupt the disk.

Comment 9 Stephen Tweedie 2004-11-29 00:42:44 UTC
Looks like I've got this one under control --- I just need to push fixed rpms
through the build system and test them in place.  I don't think any kernel
patches will be needed.

There's one other thing that turned up during testing, though --- ext2online was
falling back to an older mechanism involving the app manually modifying the live
fs if run on an ext2 volume.  That fallback is a relic of previous ext2online
work and needs to be disabled before online resize goes live.  I'll do that as
part of the same build.

Comment 10 Stephen Tweedie 2004-12-09 22:04:25 UTC
All fixes are checked in.  I've placed provisional rpms up for testing at:


Source, and binaries for i386, x86_64, ppc/ppc64 and s390/s390x are all there.

I've done basic testing on the final changes, including performing live resizes
on ppc64 and forcing a full fsck before and after the resize, and everything
looks OK so far.

Comment 11 Stephen Tweedie 2004-12-09 22:10:34 UTC
For safety, this final build of ext2online has two further one-line changes over
and above the byte-ordering fixes.  It:

 Disables fallback to the old-style online resize if the new resize ioctls are
 not present (old-style is untested and unsupported, and unlikely to be 


 Disables the write file descriptor used by that fallback path, as a failsafe in
 case it attempts to modify the fs that way --- that would be safe enough on
 ext2 but not on ext3.

Comment 12 Stephen Tweedie 2004-12-10 22:13:15 UTC
Final build is e2fsprogs-1.35-11.5, in the RHEL4 trees as of 20041210.

Note You need to log in before you can comment on or make changes to this bug.