From: Gijs <info@bsnw.nl>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM pretends it has more space than it actually has
Date: Wed, 12 Oct 2011 22:43:38 +0200 [thread overview]
Message-ID: <4E95FBFA.2020402@bsnw.nl> (raw)
In-Reply-To: <4E7A2DBC.4010701@bsnw.nl>
I managed to get all my data back by deleting the LVM volumes and
recreating it without formatting the drives. I did have to run fsck on
my data volume, but all data was intact as far as I could see.
And I also think I know what went wrong. Pretty much every reboot my
raid-1 (for /boot) and my raid-5 MD-devices switch places with each
other. So sometimes it's /dev/md126, the other times it's /dev/md127. I
must have used the wrong device after a reboot, mistakenly thinking it
was the LVM or boot partition.
On 21-9-2011 20:32, Gijs wrote:
> Unfortunately I can't find all the old LVM configs that the system
> used. I was in the process of moving my root filesystem to the raid-5
> array. Since I needed the root to be unmounted for that, I used a FC15
> USB-bootable rescue system to do the copying of the root to the raid-5
> array. And that's when things went wrong. Since the rescue system is
> pretty much run from memory, I don't have the LVM configs that were
> created when I was using the rescue system. I do have older configs
> that were created when I was creating the raid-5 array on the system
> itself, but those don't show anything wrong from what I can see. (and
> I guess that's correct, since nothing was wrong at that time)
>
> I tried assembling/recreating an array on the PV-device, but that just
> gave me the error "mdadm: no raid-devices specified." So I can't
> really find an array on the LVM devices either.
>
> Some info I got from the PV:
> [root@poseidon ~]# pvdisplay -m /dev/md127
> --- Physical volume ---
> PV Name /dev/md127
> VG Name raid-5
> PV Size 3.64 TiB / not usable 0
> Allocatable yes
> PE Size 4.00 MiB
> Total PE 952919
> Free PE 5252
> Allocated PE 947667
> PV UUID ZmJtA4-cZBL-kuXT-53Ie-7o1C-7oro-uw5GB6
>
> --- Physical Segments ---
> Physical extent 0 to 714687:
> Logical volume /dev/raid-5/data
> Logical extents 0 to 714687
> Physical extent 714688 to 714933:
> FREE
> Physical extent 714934 to 714953:
> Logical volume /dev/raid-5/data
> Logical extents 947647 to 947666
> Physical extent 714954 to 719959:
> FREE
> Physical extent 719960 to 952918:
> Logical volume /dev/raid-5/data
> Logical extents 714688 to 947646
>
> The empty spaces inbetween are from LVs there were created before. And
> the 3rd segment is from when I tried to resize the data-LV to see if
> that made any difference. It obviously didn't since it was the PV that
> was actually too small, not the LV, which I figured out later.
>
> From what you say, it indeed sounds like I messed up some command that
> caused an array to be created on an LV, but I can't really find any
> evidence that I really did that. Is there any other explanation that
> LVM is acting this way? Is it perhaps possible to tell LVM to run of
> the configuration stored in /etc/lvm, instead of the metadata embedded
> on the PV?
>
> There's also something that I don't understand. Why is it just the
> data-LV? I had a swap and root LV as well, and those activated just
> fine. Why would LVM have trouble activating the data-LV when it had no
> trouble activating the swap/root-LV?
>
> On 19-9-2011 22:41, Ray Morris wrote:
>> First, if at all possible make a copy of the underlying block
>> device using dd or dd_rescue. Very often the most severe damage
>> is done during the attempt at recovery.
>>
>> Then let's find the oldest back up copies on the LVM meta data to
>> see if we can verify how things were set up when they were working.
>> This will find metadata over 50 days old:
>>
>> find /etc/lvm/archive -mtime +50
>>
>> mainly what we're looking for is to see if any mdadm RAID devices
>> were used as PVs at some point.
>>
>> Next try mdadm --assemble --readonly --assume-clean /dev/sdFOO to see
>> if you can assemble an array using the lower level device (which is
>> also marked as a PV right now). If it assembles, do:
>> pvdisplay -m /dev/md0
>> to see if it's a PV, and check to see if it has a filesystem.
>>
>> Based on the messages you got, it looks like /dev/md0 at one point
>> was the PV, rather than being assembled from LVs.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
prev parent reply other threads:[~2011-10-12 20:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 13:58 [linux-lvm] LVM pretends it has more space than it actually has Gijs
2011-09-19 0:21 ` Stuart D. Gathman
2011-09-19 17:40 ` Gijs
2011-09-19 1:13 ` adultsitesoftware@gmail.com
2011-09-19 1:23 ` adultsitesoftware@gmail.com
2011-09-19 17:37 ` Gijs
2011-09-19 18:48 ` Ray Morris
2011-09-19 19:48 ` Gijs
2011-09-19 20:41 ` Ray Morris
2011-09-21 18:32 ` Gijs
2011-10-12 20:43 ` Gijs [this message]
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=4E95FBFA.2020402@bsnw.nl \
--to=info@bsnw.nl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.