From: "Jorge Fábregas" <jorge.fabregas@gmail.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Extend VG - Expand LUN vs New Disk
Date: Mon, 21 Dec 2015 12:13:35 -0400 [thread overview]
Message-ID: <5678252F.2040304@gmail.com> (raw)
In-Reply-To: <20151221125008.GB16946@hex.gsslab.fab.redhat.com>
On 12/21/2015 08:50 AM, Bryn M. Reeves wrote:
> Expanding an existing LUN may involve resizing partitions - that is
> normally the step that makes this the more complicated route since
> depending on system configuration and use it may not be easy to resize
> the partition without downtime (the Linux kernel has for some time
> enforced restrictions on resizing in-use partitions - device-mapper
> devices and whole disk devices do not share this limitation).
We use whole disks all the time :)
> It's safe enough - it's just that the kernel generally won't let you
> do it while the existing partition is active and in use.
I'm glad to know that: one more reason to use whole disks. I know Red
Hat favors partitions for PVs (as mentioned in various docs) but I've
never been convinced by the arguments for it.
> Expanding an existing partition may be seen as the "cleaner" option,
> since it avoids creating additional PVs and associated labels and
> metadata areas, but unless you are working with very large numbers of
> devices it makes little difference to most operations.
Excellent point.
> Gluing lots of devices together is one of the main reasons for using a
> volume manager and for typical uses it adds no appreciable overhead
> or additional complexity.
Thanks Bryn for your wonderful feedback. I appreciate it!
All the best,
Jorge
prev parent reply other threads:[~2015-12-21 16:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 12:30 [linux-lvm] Extend VG - Expand LUN vs New Disk Jorge Fábregas
2015-12-21 12:50 ` Bryn M. Reeves
2015-12-21 16:13 ` Jorge Fábregas [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=5678252F.2040304@gmail.com \
--to=jorge.fabregas@gmail.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.