Bug 144486 - RHEL3 EXT3 Offline Filesystem Resizing Issue
RHEL3 EXT3 Offline Filesystem Resizing Issue
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Jay Turner
:
Depends On:
Blocks: RHEL3U8CanFix
  Show dependency treegraph
 
Reported: 2005-01-07 12:00 EST by Mark Spencer
Modified: 2015-01-07 19:09 EST (History)
9 users (show)

See Also:
Fixed In Version: RHBA-2006-0400
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-20 10:25:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to check for super block fs before moving block and inode bitmaps (639 bytes, patch)
2006-02-23 16:34 EST, David Milburn
no flags Details | Diff

  None (edit)
Description Mark Spencer 2005-01-07 12:00:53 EST
The original client query:

HI Mark,
        We are doing some testing with EXT3.
        I am having a problem that can be reproduce very simply.
        I create an ext3 filesystem of 100M, and (trying to )
enlarging by 100M.
        The first and second enlargement work well, but not on the
third one
        I get an fsck error, the filesystem is corrupted ? 
        Can you help me on that one ?
        The script is 20 lines long and the output is after the script 

        Linux lxmq1001 2.4.21-15.EL 
        # rpm -qa | grep -i lvm
        lvm-1.0.3-15
        
        The script I am running is 
       
-------------------------------------------------------------------
        umount /coco
        lvremove -f /dev/datavg/cocolv
        lvcreate -L100M -n cocolv datavg
        mkfs.ext3 /dev/datavg/cocolv
        mkdir /coco
        mount -t ext3 /dev/datavg/cocolv /coco
        df -k /coco

        umount /coco
        e2fsadm -L+100M /dev/datavg/cocolv
        if [ $? -ne 0 ] ; then echo "Error Detected" ; read ohno ; fi
        mount -t ext3 /dev/datavg/cocolv /coco
        df -k /coco

        umount /coco
        e2fsadm -L+100M /dev/datavg/cocolv
        if [ $? -ne 0 ] ; then echo "Error Detected" ; read ohno ; fi
        mount -t ext3 /dev/datavg/cocolv /coco
        df -k /coco

        umount /coco
        e2fsadm -L+100M /dev/datavg/cocolv
        if [ $? -ne 0 ] ; then echo "Error Detected" ; read ohno ; fi
        mount -t ext3 /dev/datavg/cocolv /coco
        df -k /coco
       
-------------------------------------------------------------------


        THE SCREEN OUTPUT WHEN RUNNING THE SCRIPT 
       
-------------------------------------------------------------------

# ./ext3_test.sh 
lvremove -- doing automatic backup of volume group "datavg"
lvremove -- logical volume "/dev/datavg/cocolv" successfully removed
lvcreate -- doing automatic backup of "datavg"
lvcreate -- logical volume "/dev/datavg/cocolv" successfully created

mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25688 inodes, 102400 blocks
5120 blocks (5.00%) reserved for the super user
First data block=1
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks: 
8193, 24577, 40961, 57345, 73729

Writing inode tables: done 
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
mkdir: cannot create directory `/coco': File exists
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/datavg/cocolv 99150 4127 89903 5% /coco
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/datavg/cocolv: 11/25688 files (0.0% non-contiguous), 7377/102400
blocks
lvextend -- extending logical volume "/dev/datavg/cocolv" to 200 MB
lvextend -- doing automatic backup of volume group "datavg"
lvextend -- logical volume "/dev/datavg/cocolv" successfully extended

resize2fs 1.32 (09-Nov-2002)
Begin pass 1 (max = 12)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/datavg/cocolv is now 204800 blocks long.

e2fsadm -- ext2fs in logical volume /dev/datavg/cocolv successfully
extended to 200 MB

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/datavg/cocolv 198562 4127 184195 3% /coco
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/datavg/cocolv: 11/49400 files (0.0% non-contiguous), 10365/204800
blocks
lvextend -- extending logical volume "/dev/datavg/cocolv" to 300 MB
lvextend -- doing automatic backup of volume group "datavg"
lvextend -- logical volume "/dev/datavg/cocolv" successfully extended

resize2fs 1.32 (09-Nov-2002)
Begin pass 1 (max = 13)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 2 (max = 1)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 25)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 5 (max = 19)
Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/datavg/cocolv is now 307200 blocks long.

e2fsadm -- ext2fs in logical volume /dev/datavg/cocolv successfully
extended to 300 MB

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/datavg/cocolv 297713 4165 278188 2% /coco
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(16386--16387) -(32770--32771)
-(49154--49155) -(65538--65539) -(81922--81923) -(90114--90115)
-(98306--98307) -(106498--106499) -(114690--114691) -(122882--122883)
-(131074--131075) -(139266--139267) -(147458--147459)
-(155650--155651) -(163842--163843) -(172034--172035)
-(180226--180227) -(188418--188419) -(196610--196611)
Fix<y>?

Steven's response to the problem:

Hi,

On Thu, 2005-01-06 at 19:51, Derek Anderson wrote:

> - It is reproducible on my lab machines
> - It is also reproducible using ext2 instead of ext3

Right.  It's clearly a bug; it's trivial to reproduce; and the current
upstream bitkeeper e2fsprogs tree does not show the problem.

I'm using the attached script to reproduce.  It can be run from the top
level of an e2fsprogs build tree, so you can test a fixed build as well
as the installed version (remember to build with ./configure
--disable-shared if you do that, to avoid picking up the
already-installed libext2fs libraries.)

Please open a bug against e2fsprogs and make sure I'm CC:ed on it.

So far the only corruption I've seen is blocks incorrectly marked
in-use, so fortunately the impact is limited and if this is the only
symptom, it will not lead to data corruption.  The problem also appears
to be confined to blocksizes smaller than 4k; a 4k-blocksize fs doesn't
show the problem for me, and all sufficiently-large (I think it's >=1G)
filesystems are created with 4k blocksize by default anyway these days. 
But a 100MB fs gets 1k blocksize so shows the problem.

--Stephen


			shell script attachment (simple-resize2fs.sh), ""

#!/bin/bash

FSIMG=/tmp/fs.img

RESIZE=resize/resize2fs
E2FSCK=e2fsck/e2fsck
MKE2FS=misc/mke2fs

if [ ! -x $RESIZE ] ; then RESIZE=/sbin/resize2fs; fi
if [ ! -x $E2FSCK ] ; then E2FSCK=/sbin/e2fsck; fi
if [ ! -x $MKE2FS ] ; then MKE2FS=/sbin/mke2fs; fi

if [ ! -x $RESIZE ] ; then echo No resize2fs found; exit 1; fi
if [ ! -x $E2FSCK ] ; then echo No e2fsck found; exit 1; fi
if [ ! -x $MKE2FS ] ; then echo No mke2fs found; exit 1; fi

echo Using resize2fs at $RESIZE
echo Using e2fsck at $E2FSCK
echo Using mke2fs at $MKE2FS

touch $FSIMG
> $FSIMG

set -x

$MKE2FS -F $FSIMG 100000 || exit 1
$E2FSCK -fn $FSIMG || exit 1
$RESIZE $FSIMG 300000 || exit 1
$E2FSCK -fn $FSIMG || exit 1

rm -f $FSIMG
Comment 1 Stephen Tweedie 2005-01-07 12:26:04 EST
I've reproduced this with the RHEL3 e2fsprogs, and it appears to be
fixed in current upstream e2fsprogs.
Comment 2 Mark Spencer 2005-01-07 14:27:36 EST
The client forwards me this update by e-mail:

I read the response from Steven, and by forcing the blocksize to 4K
when creating the FS, the problem disappears.

MS
Comment 8 David Milburn 2006-02-23 16:34:30 EST
Created attachment 125138 [details]
Patch to check for super block fs before moving block and inode bitmaps
Comment 9 David Milburn 2006-02-23 16:37:55 EST
This is a e2fsprogs-1.32-15.1 patch based upon 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174766

Comment 13 Erwan Velu 2006-03-23 05:44:04 EST
I also had this troubles, applying the patch attached in the debian's BTS on the
1.32.15.1 had fixed our troubles.

Is it possible to have an official update for this important bug ?
Comment 20 Red Hat Bugzilla 2006-07-20 10:25:34 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0400.html

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