From: Ray Morris <support@bettercgi.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Strange behavior adding LUN
Date: Mon, 20 Feb 2012 14:40:53 -0600 [thread overview]
Message-ID: <20120220144053.053ac4e2@bettercgi.com> (raw)
In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB6B2AB35166@off-win2003-01.ausregistrygroup.local>
> So, weird. Why is the 'pvcreate' seeing the new LUN, seeing that it
> is 2.93TB, but not creating any PE's for use.
You need to vgextend. The PE size is a property of the VG, so until
it's added to a VG there's no way of knowing how big the PEs are and
therefore how many will fit on the PV.
--
Ray Morris
support@bettercgi.com
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On Mon, 20 Feb 2012 10:26:05 +1100
Stuart Browne <stuart.browne@ausregistry.com.au> wrote:
> Hi,
>
> We've been cleaning up some of our storage recently and migrating to
> new disks etc. when I came across this issue.
>
> I've re-allocated some old storage back to a server as a new array,
> but lvm is refusing to allow the LUN to participate. Here's what I
> see:
>
> [root@office ~]# pvcreate /dev/mpath/backup1
> Physical volume "/dev/mpath/backup1" successfully created
> [root@office ~]# pvdisplay /dev/mpath/backup1
> "/dev/mpath/backup1" is a new physical volume of "2.93 TB"
> --- NEW Physical volume ---
> PV Name /dev/mpath/backup1
> VG Name
> PV Size 2.93 TB
> Allocatable NO
> PE Size (KByte) 0
> Total PE 0
> Free PE 0
> Allocated PE 0
> PV UUID ipTgcI-kjdJ-Aucx-cUVs-TWKr-wAFO-Rkd0u8
>
> Thinking it's somehow mussed up the labelling, I had a quick look at
> the disk header:
>
> [root@office ~]# dd if=/dev/mpath/backup1 bs=1k count=1 | cat -v -
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@LABELONE^A^@^@^@^@^@^@^@M-Tl^LM-z
> ^@^@^@LVM2
> 001ipTgcIkjdJAucxcUVsTWKrwAFORkd0u8^@^@^@^@M-n^B^@^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P^@^@^@^@^@^@^@M-p^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1+0
> records in 1+0 records out 1024 bytes (1.0 kB) copied, 0.000809
> seconds, 1.3 MB/s
>
> Given that it looks, well, 'ok' to me, I thought I'd 'pvremove' it
> and validate that the disk is empty. It was (^@'s all the way, for
> the first 10MB at least), and re-add it. New UUID, but basically the
> same.
>
> So, weird. Why is the 'pvcreate' seeing the new LUN, seeing that it
> is 2.93TB, but not creating any PE's for use.
>
> Anybody have any idea what I should try next?
>
> Stuart J. Browne
> Senior Unix Administrator, Network Administrator, Database
> Administrator AusRegistry Pty Ltd
> Level 8, 10 Queens Road
> Melbourne. Victoria. Australia. 3004.
> Ph:Â +61 3 9866 3710
> Fax: +61 3 9866 1970
> Email: stuart.browne@ausregistry.com.au
> Web: www.ausregistry.com.au
>
> The information contained in this communication is intended for the
> named recipients only. It is subject to copyright and may contain
> privileged and/or confidential information. If you are not an
> intended recipient you must not use, copy, distribute or take any
> action in reliance on it. If you have received this communication in
> error, please delete all copies from your system and notify us
> immediately.
>
>
next prev parent reply other threads:[~2012-02-20 20:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 23:26 [linux-lvm] Strange behavior adding LUN Stuart Browne
2012-02-20 20:40 ` Ray Morris [this message]
2012-02-20 22:47 ` Stuart Browne
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=20120220144053.053ac4e2@bettercgi.com \
--to=support@bettercgi.com \
--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.