[linux-lvm] Rebuilding ext4 filesystem on an LV

[Ken Bass]

On Mon, Jul 5, 2010 at 3:06 AM, Bryan Whitehead <driver at megahappy.net>wrote:

>
> The lv is available right?
>
> It would be great to see the output from lvdisplay and vgdisplay.
>
> -Bryan
>
>
___________________________________
[root at Elmer ken]# lvdisplay /dev/VolGroupX/LogVolX
  --- Logical volume ---
  LV Name                /dev/VolGroupX/LogVolX
  VG Name                VolGroupW
  LV UUID                eBQgqM-RHra-ruaK-CcEt-stnX-U9yR-Uz4UH5
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                442.80 GB
  Current LE             113358
  Segments               5
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:11

[root at Elmer ken]# vgdisplay VolGroupX
  --- Volume group ---
  VG Name               VolGroupX
  System ID
  Format                lvm2
  Metadata Areas        5
  Metadata Sequence No  28
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                5
  Act PV                5
  VG Size               442.80 GB
  PE Size               4.00 MB
  Total PE              113358
  Alloc PE / Size       113358 / 442.80 GB
  Free  PE / Size       0 / 0
  VG UUID               2CXUUY-j6nu-07qP-kKd1-ZkBJ-hNwf-iunkwK

___________________________________

I would think I should be able to find a backup superblock among the
remaining drives. I tried running mke2fs -n to get a list of possible
superblocks, but when I ran e2fsck with those values, I got the ioctl error,
and then the no superblock found message.

Is there any way to scan each of the individual drives for data, outside of
LVM? Just another desparate thought.

thx again.

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20100705/852b24c0/attachment.htm>