From: Andrew Ragone <ajr9166@rit.edu>
To: linux-lvm@redhat.com
Subject: [linux-lvm] Volume Group and XFS Partition Recovery
Date: Sat, 03 Jul 2010 13:15:14 -0400 [thread overview]
Message-ID: <AANLkTikgkIeGAaT5DL4Xc5Y-1vD2kQYevg_p0ka-MYYX@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]
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.
Thanks,
Andrew
[-- Attachment #2: Type: text/html, Size: 8480 bytes --]
reply other threads:[~2010-07-03 17:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikgkIeGAaT5DL4Xc5Y-1vD2kQYevg_p0ka-MYYX@mail.gmail.com \
--to=ajr9166@rit.edu \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).