All of lore.kernel.org
 help / color / mirror / Atom feed
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, 21 Sep 2011 20:32:28 +0200	[thread overview]
Message-ID: <4E7A2DBC.4010701@bsnw.nl> (raw)
In-Reply-To: <20110919154141.3ab847af@bettercgi.com>

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.

  reply	other threads:[~2011-09-21 18:32 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 [this message]
2011-10-12 20:43             ` Gijs

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=4E7A2DBC.4010701@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.