openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Sat, 9 Feb 2013, Davide Guerri wrote:

> Brady, thanks for the infos and for the bugzilla link.
>
> I made some tests and some some other researches about potential performance penalties of LVM. These seem not to be noticeable especially with recent linux versions. (please see for instance [1]).
>
> Now I'm even more curious about the choice of canonical: there must be a good reason for using such "rough" (pass me the term) filesystem resize technique over a more clean and practical lvm resize.

LVM is a wonderfully useful technology for making multiple physical
volumes appear as a single block device.  LVM could definitely work here
and arguably results in a more feature-laiden selection for the block
layer of a root filesystem.

However, for a cloud-guest, the environment is just massively different
than on a physical server.  You're no longer limited by the fact that your
server has 3 physical disks each 360G in size.  You're not exposed to
that.  You have a root device that can be anywhere from 1G to some large
number.  You can attach more of those same block devices later on with an
API call (as opposed to a sys-admin or call to a storage vendor).

To be clear, I'm *not* saying LVM is not suited for the task of being the
block layer.  I'm saying it is less necessary in a "cloud" world.

Thanks to Juerg, kernel, and util-linux, With the next version of
cloud-init and growpart, we'll be able to resize the root filesystem on a
partition outside of the initramfs.  I'll gladly accept patches or bugs to
cloud-init if that doesn't work for root on LVM disks.