linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] Strange behavior adding LUN
@ 2012-02-19 23:26 Stuart Browne
  2012-02-20 20:40 ` Ray Morris
  0 siblings, 1 reply; 3+ messages in thread
From: Stuart Browne @ 2012-02-19 23:26 UTC (permalink / raw)
  To: linux-lvm@redhat.com

[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]

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.



[-- Attachment #2: pvcreate.txt --]
[-- Type: text/plain, Size: 9536 bytes --]

[root@office ~]# pvcreate -vvvv /dev/mpath/backup1
#lvmcmdline.c:1089         Processing: pvcreate -vvvv /dev/mpath/backup1
#lvmcmdline.c:1092         O_DIRECT will be used
#config/config.c:994       Setting global/locking_type to 1
#config/config.c:994       Setting global/wait_for_locks to 1
#locking/locking.c:240       File-based locking selected.
#config/config.c:971       Setting global/locking_dir to /var/lock/lvm
#libdm-common.c:430         Preparing SELinux context for /var/lock/lvm to system_u:object_r:lvm_lock_t.
#libdm-common.c:433         Resetting SELinux context to default value.
#config/config.c:977       metadata/pvmetadataignore not found in config: defaulting to n
#config/config.c:999       metadata/pvmetadatasize not found in config: defaulting to 255
#config/config.c:999       metadata/pvmetadatacopies not found in config: defaulting to 1
#locking/file_locking.c:235       Locking /var/lock/lvm/P_orphans WB
#libdm-common.c:430         Preparing SELinux context for /var/lock/lvm/P_orphans to system_u:object_r:lvm_lock_t.
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_orphans:aux WB
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_orphans WB
#locking/file_locking.c:51         _undo_flock /var/lock/lvm/P_orphans:aux
#libdm-common.c:433         Resetting SELinux context to default value.
#ioctl/libdm-iface.c:2005         dm version   OF   [16384]
#ioctl/libdm-iface.c:2005         dm status   (253:3) OF   [16384]
#device/dev-io.c:495         Opened /dev/mpath/backup1 RO O_DIRECT
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#filters/filter-composite.c:31         Using /dev/mpath/backup1
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#label/label.c:184       /dev/mpath/backup1: No label detected
#device/dev-io.c:541         Closed /dev/mpath/backup1
#ioctl/libdm-iface.c:2005         dm status   (253:3) OF   [16384]
#device/dev-io.c:495         Opened /dev/mpath/backup1 RO O_DIRECT
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#filters/filter-composite.c:31         Using /dev/mpath/backup1
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_EXCL O_DIRECT
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#ioctl/libdm-iface.c:2005         dm status   (253:3) OF   [16384]
#device/dev-io.c:495         Opened /dev/mpath/backup1 RO O_DIRECT
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:541         Closed /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#filters/filter-composite.c:31         Using /dev/mpath/backup1
#device/dev-io.c:268       /dev/mpath/backup1: size is 6291456000 sectors
#config/config.c:994       Setting devices/data_alignment to 0
#config/config.c:994       Setting devices/default_data_alignment to 0
#metadata/metadata.c:126       /dev/mpath/backup1: Setting PE alignment to 128 sectors.
#metadata/metadata.c:159       /dev/mpath/backup1: Setting PE alignment offset to 0 sectors.
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:730         Wiping /dev/mpath/backup1 at sector 8 length 8 sectors
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#metadata/metadata.c:1499     Set up physical volume for "/dev/mpath/backup1" with 6291456000 available sectors
#label/label.c:203       Scanning for labels to wipe from /dev/mpath/backup1
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#metadata/metadata.c:1508     Zeroing start of device /dev/mpath/backup1
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:730         Wiping /dev/mpath/backup1 at sector 0 length 4 sectors
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#device/dev-io.c:541         Closed /dev/mpath/backup1
#metadata/metadata.c:1523       Writing physical volume data to disk "/dev/mpath/backup1"
#cache/lvmcache.c:1166         lvmcache: /dev/mpath/backup1: now in VG #orphans_lvm2 (#orphans_lvm2)
#format_text/format-text.c:1453         Creating metadata area on /dev/mpath/backup1 at sector 8 size 376 sectors
#format_text/format-text.c:1523       /dev/mpath/backup1: setting pe_start=384 (orig_pe_start=384, pe_align=128, pe_align_offset=0, adjustment=0)
#device/dev-io.c:495         Opened /dev/mpath/backup1 RW O_DIRECT
#device/dev-io.c:134         /dev/mpath/backup1: block size is 4096 bytes
#format_text/text_label.c:137         /dev/mpath/backup1: Preparing PV label header sVsk4g-FEwG-nQfC-3xqX-Oc3B-Ytee-KH6rFe size 3221225472000 with da1 (384s, 0s) mda1 (8s, 376s)
#label/label.c:334       /dev/mpath/backup1: Writing label to sector 1 with stored offset 32.
  Physical volume "/dev/mpath/backup1" successfully created
#locking/file_locking.c:74       Unlocking /var/lock/lvm/P_orphans
#locking/file_locking.c:51         _undo_flock /var/lock/lvm/P_orphans
#device/dev-io.c:541         Closed /dev/mpath/backup1

[root@office ~]# dd if=/dev/mpath/backup1 bs=1k count=1 | cat -v -
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@LABELONE^A^@^@^@^@^@^@^@,M->M-aM-R ^@^@^@LVM2 001sVsk4gFEwGnQfC3xqXOc3BYteeKH6rFe^@^@^@^@M-n^B^@^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P^@^@^@^@^@^@^@M-p^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.01024 seconds, 100 kB/s
[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               sVsk4g-FEwG-nQfC-3xqX-Oc3B-Ytee-KH6rFe


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] Strange behavior adding LUN
  2012-02-19 23:26 [linux-lvm] Strange behavior adding LUN Stuart Browne
@ 2012-02-20 20:40 ` Ray Morris
  2012-02-20 22:47   ` Stuart Browne
  0 siblings, 1 reply; 3+ messages in thread
From: Ray Morris @ 2012-02-20 20:40 UTC (permalink / raw)
  To: linux-lvm

> 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.
> 
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] Strange behavior adding LUN
  2012-02-20 20:40 ` Ray Morris
@ 2012-02-20 22:47   ` Stuart Browne
  0 siblings, 0 replies; 3+ messages in thread
From: Stuart Browne @ 2012-02-20 22:47 UTC (permalink / raw)
  To: LVM general discussion and development

Huh, nice to know I missed such an obvious step.

Cheers ;)

Stuart

> -----Original Message-----
> From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com]
> On Behalf Of Ray Morris
> Sent: Tuesday, 21 February 2012 7:41 AM
> To: linux-lvm@redhat.com
> Subject: Re: [linux-lvm] Strange behavior adding LUN
> 
> > 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
> >
<snip>
> >
> > 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
> 
> _______________________________________________
> 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/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-02-20 22:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-19 23:26 [linux-lvm] Strange behavior adding LUN Stuart Browne
2012-02-20 20:40 ` Ray Morris
2012-02-20 22:47   ` Stuart Browne

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).