Ext3 users - Feb 2005 - e2fsck errors after lvextend when trying to resize2fs

I found a thread that has almost the exact same symptoms as me, but didn't 
seem to come to a resolution:
https://listman.redhat.com/archives/ext3-users/2004-December/msg00018.html

I have an LVM(2) array that I've just lvextend'd and want to resize2fs,
but I
can't get through the e2fsck.  I get these errors when fsck-ing:

Group 3125's inode table at 102400545 conflicts with some other fs block.
Relocate? yes
Group 3125's inode table at 102400546 conflicts with some other fs block.
Relocate? yes
Group 3125's inode table at 102400547 conflicts with some other fs block.
Relocate? yes
Group 3125's block bitmap at 102400034 conflicts with some other fs block.
Relocate? yes
Group 3125's inode bitmap at 102400035 conflicts with some other fs block.
Relocate? yes

And contines to fsck, but then restarts the fsck around 66% and the exact same 
errors occur again.   If I cancel the fsck, I can still mount the partition 
and everything seems fine, but I can't resize the partition without getting 
through the fsck.  Any thoughts?  Let me know if I need to provide any more 
information.

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20050206/bd96294f/attachment.sig>

Douglas E. Warner wrote:
> I found a thread that has almost the exact same symptoms as me, but
didn't
> seem to come to a resolution:
> https://listman.redhat.com/archives/ext3-users/2004-December/msg00018.html
This was me. My solution:

mkreiserfs /dev/...

Luckily, the only partition of mine that got corrupted was my backup 
partition, so it was trivial to re-create this simply by running my 
backup scripts again after formatting the partition as reiser.

I then converted all my other partitions over to reiser, luckily having 
left enough unpartitioned space on my disk to create some temp 
partitions for use during the conversion.

Whilst there were (I think?) some (potential?) solutions listed in that 
thread, since the issue seemed very complicated, I wasn't convinced that 
it would be solved with a simple update to the FC3 RPMs. I think that 
even if I had stuck with ext3, I would have needed to reformat my 
partitions anyway, so switching fs type was no extra work. I tested out 
reiserfs, and found that resizing worked out of the box without any 
workarounds, and figured that was safer than hopefully remembering to do 
the required workarounds/fixes.

-- 
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren at wwwdotorg.org     http://www.wwwdotorg.org/pgp.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20050206/49d9e710/attachment.sig>

I should also note that this happened on the second resize for the array.  I 
started with a single disk, then was able to add a second disk fine 
(lvextend, e2fsck, resize2fs).  Only after this next lvextend I cannot 
proceed past the e2fsck.
I'll try to include some more details about my setup below.

-Doug

# cat /etc/fedora-release
Fedora Core release 3 (Heidelberg)

# uname -a
Linux thor.home.silfreed.net 2.6.10-1.760_FC3smp #1 SMP Wed Feb 2 00:29:03 EST 
2005 i686 i686 i386 GNU/Linux

# pvdisplay
  --- Physical volume ---
  PV Name               /dev/hde
  VG Name               StorageArray
  PV Size               372.59 GB / not usable 0
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              11923
  Free PE               0
  Allocated PE          11923
  PV UUID               GxQUjD-faST-c2aA-MgQg-Y78a-GwrD-gD3l1y

  --- Physical volume ---
  PV Name               /dev/hdi
  VG Name               StorageArray
  PV Size               152.66 GB / not usable 0
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              4885
  Free PE               0
  Allocated PE          4885
  PV UUID               Vr7dmh-7wTx-RiqP-ndOq-SJa8-H0Ug-ssU0dN

  --- Physical volume ---
  PV Name               /dev/hdk
  VG Name               StorageArray
  PV Size               114.47 GB / not usable 0
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              3663
  Free PE               0
  Allocated PE          3663
  PV UUID               NaNqVE-JxjU-lo52-TUrN-2k8m-YShA-mOYEiY

  --- Physical volume ---
  PV Name               /dev/sda
  VG Name               StorageArray
  PV Size               232.88 GB / not usable 0
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              7452
  Free PE               0
  Allocated PE          7452
  PV UUID               7b1GCZ-1dVx-93ho-f1D9-k0AK-LuNF-DchmiY

# lvdisplay
  --- Logical volume ---
  LV Name                /dev/StorageArray/lvol0
  VG Name                StorageArray
  LV UUID                OXdAij-4vy0-o8B2-40bk-AhAc-tuRo-Ur5QIy
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                872.59 GB
  Current LE             27923
  Segments               4
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:0

# vgdisplay
  --- Volume group ---
  VG Name               StorageArray
  System ID
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               872.59 GB
  PE Size               32.00 MB
  Total PE              27923
  Alloc PE / Size       27923 / 872.59 GB
  Free  PE / Size       0 / 0
  VG UUID               kSWgYl-4FN2-HC3O-XdIM-nSnZ-QM2V-dxQFlc

# dumpe2fs /dev/StorageArray/lvol0
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name:   StorageArray
Last mounted on:          <not available>
Filesystem UUID:          c7cebb3e-eea2-4905-9eb1-ce2ebd9b8f2f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode filetype sparse_super 
large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              68845568
Block count:              137691136
Reserved block count:     0
Free blocks:              18826646
Free inodes:              68824841
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Mon Dec 20 14:01:34 2004
Last mount time:          Sun Feb  6 17:40:31 2005
Last write time:          Sun Feb  6 18:50:24 2005
Mount count:              3
Maximum mount count:      -1
Last checked:             Sat Feb  5 18:47:06 2005
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      4054770a-3868-4699-82c4-6e7346ad18d2
Journal backup:           inode blocks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20050207/33d01589/attachment.sig>

On Sun, Feb 06, 2005 at 08:08:22PM -0500, Douglas E. Warner
wrote:
> I found a thread that has almost the exact same symptoms as me, but
didn't
> seem to come to a resolution:
> https://listman.redhat.com/archives/ext3-users/2004-December/msg00018.html
> 
> I have an LVM(2) array that I've just lvextend'd and want to
resize2fs, but I
> can't get through the e2fsck.  I get these errors when fsck-ing:
> 
> Group 3125's inode table at 102400545 conflicts with some other fs
block.
> Relocate? yes
This is cuased by a bug in Fedora Core 3's e2fsprogs.  It had patches
to support the new on-line resizing, but those patches were
incomplete, and off-line resize (i.e., resize2fs) was broken.  The
fixes have been out for a while, and e2fsprogs 1.36 has the fixes that
will resolve this problem.  Please see the RELEASE-NOTES file in
e2fsprogs 1.36 for more details:

    All of the patches that were applied to Fedore Core 3's
    e2fsprogs-1.35-11.2 have been integrated, although sometimes with a
    lot of bug fixes first.  Users of Fedora Core 3 are strongly
    encouraged to upgrade to e2fsprogs 1.36 as soon as possible.

    Add support for filesystem with the online resizing via resize inode
    feature.  Fixed numerous bugs from the Fedora patches.  The Fedora
    patches also didn't bother to do any consistency checking on the
    resize inode, or add any tests to the regression test suite.  The "-R
    resize=4g" option to mke2fs was a no-op in the Fedora patches, despite
    being listed in mke2fs's usage message.  All of these shortcomings
    have been corrected.

    E2fsck can also also fix filesystems trashed by Fedora's resize2fs
    program.  In order to do this, the user must run the commands:

    	debugfs -w /dev/hdXXX -R "features ^resize_inode
            e2fsck -f /dev/hdXXX

    Optionally, the ext2prepare command can be used to re-enable online
    resizing after the filesystem has been fixed.

							- Ted