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. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp