All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hawtin <oolon@ankh.org>
To: Marek Podmaka <marki@marki-online.net>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] N00b Question: Logical Volume without a Logical	Volume Group ?
Date: Wed, 02 Nov 2011 13:37:40 +0000	[thread overview]
Message-ID: <4EB147A4.4070805@ankh.org> (raw)
In-Reply-To: <581100587.20111102124129@marki-online.net>

Marek Podmaka wrote:
> Hello,
>
> Wednesday, November 2, 2011, 11:18:50, James Hawtin wrote:
>
>   
>> Personally even with LVM I would still write a partition table the disk,
>> this helps show the disk as being used to other system administrators,
>> however there would be one partition on it of type 8e, and on that I 
>> would create a PV (physical volume), this PV can then be used to create
>>     
>
> How do you extend the PV then? For example extend the LUN on storage
> or just resize a RAID1+0 set by adding 2 new disks... Resizing the
> block device is no problem, resizing the PV also, but to resize the
> PV, you need to resize the partition also - and if I remember well,
> the kernel won't re-read the new partition table while it is used...
>
>
>   
I never have need to extend a PV, I just add a new piece of disk (LUN) 
to the server, create a PV on that and extend the volume group and LV. 
There is pvresize if you really  want to extend an lun, that could be 
used after making the disk larger or fdisking more space, however I 
never have need to do that, I pretty much always present a new lun. You 
can also create a second partition on a larged disk and then create a PV 
on that too... LVM is designed to join all your bits of disk together, 
so you don't have to need one continue peice of space to provide the disk.

Using pvmove I can allocate a larger new piece of disk and online move 
all the data from an old pv to a new one as well. In my experence with 
working with large san system rays are not in general extended, whole 
new ones are added instead. Personally I would not extend and existing 
array with an additional mirror concat, I would prefer to use raid 10 or 
use software striping in LVM with seperately presented LUNs for each 
mirrored pair as that would work the disk harder.

James

  reply	other threads:[~2011-11-02 13:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 18:39 [linux-lvm] N00b Question: Logical Volume without a Logical Volume Group ? Dan White
2011-11-01 18:45 ` Digimer
2011-11-01 19:13   ` Dan White
2011-11-01 19:20     ` Digimer
2011-11-01 19:51       ` Dan White
2011-11-02 14:02         ` Mark H. Wood
2011-11-01 21:09 ` Ray Morris
2011-11-02 10:18 ` James Hawtin
2011-11-02 11:41   ` Marek Podmaka
2011-11-02 13:37     ` James Hawtin [this message]
2011-11-02 14:18     ` Mark H. Wood
2011-11-02 14:50       ` Marek Podmaka
2011-11-02 14:56         ` James Hawtin
2011-11-02 15:06           ` Dan White
2011-11-02 16:39             ` James Hawtin
2011-11-02 17:30               ` Eugene Vilensky
2011-11-02 18:23               ` Dan White
2011-11-02 18:41                 ` Dan White
2011-11-02 17:57             ` Galen Seitz
2011-11-03  6:53             ` Marek Podmaka

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=4EB147A4.4070805@ankh.org \
    --to=oolon@ankh.org \
    --cc=linux-lvm@redhat.com \
    --cc=marki@marki-online.net \
    /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.