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