[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] Volume Group and XFS Partition Recovery

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 follows:

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 this:

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 /dev/oasis/puddle

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 case?

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. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]