[linux-lvm] Volume Group and XFS Partition Recovery

Andrew Ragone ajr9166 at rit.edu
Sat Jul 3 17:15:14 UTC 2010

Hey everyone:

I hope everyone's summers have been exciting so far. The other day mine had
a little hiccup thrown in there that I was hoping some of the bright members
of this group could shed some light on. Rundown of the problem is as

Alright so I have an XFS partition inside of a volume group on my server.
It's been configured as such for awhile and is functional. Regardless, I
recently added some drives and expanded the raid on my 3ware card
successfully from 14 TB to 20TB. Of course the next step is to expand the
partition and then the file system. (The partition lives in a Volume Group
in a Logical Volume). I have done this entire process once before
successfully without data loss when expanding from 10TB to 14TB but for some
reason it all blew up in my face this time. Commands used were similar to

umount -a (unmount all partitions)

      vgchange -an (disable all volume groups)
      partprobe (reread partition tables on all disks)
      parted /dev/sda resize 1 0.017 267466 (resize the partition)
      partprobe (reread partition tables on all disks)
      pvresize /dev/<disk_partition> (resize the physical volume << seems to
be about the point this went awry)
      vgchange -ay (enable all volume groups)
      mount -a (remount all disk partitions)

Basically I've got things in this strange state where the partition
/dev/sda1 (being based off the logical block device for the raid) looks like
it has successfully expanded from End Cylinder 1945212 (previous config) to
267466 (using all 20 TB) but can't be mounted. It actually seems to have
initially disappeared from the volume group listing (correct me if this
terminology is wrong): initially the block device was mapped to
/dev/oasis/puddle yet /dev/oasis is now empty. So to "recapture" the
partition I tried to all a new v
 olume group now called vol0x that should house the /dev/sda1 physical
volume. Of course in /dev/oasis I show only /dev/oasis/vol0x and not

On this, my question is* can I reconfigure volume groups and logical volumes
on the fly in order to "recapture" the actual partition without affecting
the data?* If I am correct, the data is only a simple mapping in the GPT
table on the first sector of the drive.

Further, the actual volume group that houses the XFS file system now exists
as "lvm2pv" which I'm fairly certain needs to be "xfs". Should this be the

I've shut down the machine so no data is accessed, attempted to be accessed,
etc. until I can get some ideas on recovery approach.

   - Basically, can anyone provide some insight on what order LVs, PVs, and
   VGs need to be configured to work properly?
   - What are some approaches to attempt to grab this data back?
      - Is anyone familiar with what xfs_repair does and how I might be able
      to apply it here?
      - Worse case scenario: having software such as TestDisk remap the file
      info, though I've read XFS is a huge pain in filesystem world to
do this on.

Somehow the mapping of the file system to the physical volume blew up and at
this point I think I just need to play with the pointers in the Logical
Volumes, Volume Groups, and file system types in the partition. But I have
had limited experience with this advanced of a problem and having to adapt 3
objects with the same parameters to work in unison and give me my data back
gets complicated very quickly and just wanted to see if there are a few
minds to bounce ideas off of and help out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20100703/f9073051/attachment.htm>

More information about the linux-lvm mailing list