I've got 6 drives (each 1.5T, all same model and firmware revision) that are part of a RAID5 array. The RAID5 makes a LVM volume group and a logical group. The latter contains only one ext3 partition. I've recently ran:

e2fsck -f /dev/vg03/lv01 && resize2fs -M /dev/vg03/lv01

which exited without an error.

Now when I try to mount /dev/vg03/lv01 I get:

EXT3-fs error (device dm-0): ext3_check_descriptors: Block bitmap for group 30533 not in group (block 1000532368)!
  EXT3-fs: group descriptors corrupted!

How do I get out of this predicament? This is all the info I can currently give you:

fdisk -l /dev/sd[cdefgh] shows (correctly) that they are "Linux raid autodetect"

but fdisk now shows:

fdisk -l /dev/md0

Disk /dev/md0: 7501.5 GB, 7501495664640 bytes

Disk identifier: 0x00000000
Disk /dev/md0 doesn't contain a valid partition table

(instead of a LVM type partition)

fdisk -l /dev/vg03/lv01

Disk /dev/vg03/lv01: 7501.5 GB, 7501491732480 bytes
Disk identifier: 0x00000000
Disk /dev/vg03/lv01 doesn't contain a valid partition table

(instead of a ext3 type partition)

I've tried:

e2fsck -fy /dev/vg03/lv01

e2fsck 1.41.12 (17-May-2010)
e2fsck: Group descriptors look bad... trying backup blocks...
Block bitmap for group 30533 is not in group. (block 1000532368)
Relocate? yes

Inode bitmap for group 30533 is not in group. (block 1000532369)
Relocate? yes

Pass 1: Checking inodes, blocks, and sizes
Relocating group 30533's block bitmap to 1000524246...
Error allocating 1 contiguous block(s) in block group 30533 for inode bitmap: Could not allocate block in ext2 filesystem
e2fsck: aborted

Extra information I can give you:

cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (auto-read-only) raid5 sdg1[0] sdh1[5] sdf1[4] sde1[3] sdc1[2] sdd1[1]
7325679360 blocks level 5, 128k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 1/175 pages [4KB], 4096KB chunk

unused devices:

Lastly, all smartctl tests (short and extendend) showed no errors on any of the disks.

Should I try to resize2fs to grow /dev/vg03/lv01 and redo a e2fsck ? Should I cfdisk /dev/md0 and /dev/vg03/lv01 back to their real types?

Thanks in advance for all and any help.

2011-09-20 UPDATE

I issued the following commands and was able to remount the partition, but by viewing the size (df) of before and after, it seems that 1Tb of data have gone missing. By checking the MD5SUMS (from an old backup) of some files with the "same" files from the remounted partition, some errors have been detected.

Commands issued to remount the partition were:

dumpe2fs /dev/vg03/lv01

  Block count: 1000491435<br />
  Block size:  4096<br />

tune2fs -O ^has_journal /dev/vg03/lv01

resize2fs -p /dev/vg03/lv01

dumpe2fs /dev/vg03/lv01

  Block count: 1831418880<br />
  Block size:  4096<br />

mount -o ro,noatime /dev/vg03/lv01 /mnt/raid

  OK... but files have been damaged / gone missing.

2 Answers 2


How did you create the LVM in the first place? Did you prepare the physical volume using /dev/md0 or did you do an fdisk first and use one of the partitions as the physical volume.

If you used the entire device as a PV then fdisk is not going to work on it as the LVM information will be placed where fdisk expects to find a partition table.

What you might want to check is to do a vgdisplay -v /dev/vg03 to see what the physical volumes are present in the volume group.

  • By memory, I've first created the RAID5 from /dev/sd[cdefgh]1 (Linux Raid Autodetect). Then I pvcreate'd and vgcreate'd on /dev/md0: pvscan: PV /dev/md0 VG vg03 lvm2 [6.82 TiB / 0 free] Total: 1 [6.82 TiB] / in use: 1 [6.82 TiB] / in no VG: 0 [0 ]| Finally I mke2fs the ext3, probably with either option "largefile" or "largefile4" to lower the inode ratio.
    – BlakBat
    Sep 20, 2011 at 8:26
  • You might want to do a vgscan.
    – mdpc
    Sep 20, 2011 at 20:06

You have raid 5 from 6 sd* block devices without partitions. Now, you have lvm on raid md0. So, you create physycal volume from md0, volume group named vg03 and one logical volume named lv01. lv01 consist of ext3 filesystem, wich you wants to grow/shrink.

By performing that action: e2fsck -f /dev/vg03/lv01 && resize2fs -M /dev/vg03/lv01 you trying to shrinking filesystem, which was exacly ext3 (with journal).

As far as i know resize2fs can resize ext2 file systems, but not ext3 file systems, so you must remove journal at first.

Now, when you do it by tunefs, you can get back to work filesystem, wich was broken by resize2fs and fsck later.

On that point, i can advice you only to use some specific recovery software, like ext3 undelete or whatever...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .