[openstack-dev] Feedback wanted please on proposal to make root disk size variable

Robert Collins robertc at robertcollins.net
Wed Jun 5 19:24:30 UTC 2013


On 6 June 2013 06:50, Scott Moser <smoser at ubuntu.com> wrote:

> The time and IO it takes to create a filesystem on a "device" (file or
> block device, doens't really matter) is very real.  I think the caching of
> that is not an insignificant performance improvement.
>
> Heres an example:
> $ truncate --size=20G my.img
> $ ls -s my.img
> 0 my.img
> $ time mkfs.ext3 -F my.img >/dev/null 2>&1
> real  0m15.279s
> user  0m0.020s
> sys   0m0.980s
> $ ls -s my.img
> 464476 my.img
>
> So it looks to me that it did ~400M of IO in order to put a filesystem on
> a 20G image.  If you push that off to the guest, its only going to perform
> worse (as IO will be slower).

For ext4 this is:
$ truncate --size=20G my.img
$ ls -s my.img
0 my.img
$ time mkfs.ext4 -F my.img >/dev/null 2>&1

real    0m1.408s
user    0m0.060s
sys     0m0.096s
$ ls -s my.img
135480 my.img


Does anyone use ext3 these days? ;)

Seriously though, I think keeping existing expectations as simple and
robust as possible is important. I know I was weirded out ~ a year
back when I spun up an HPCS ultra large instance and got 10G on / and
1T on /mnt : on EC2 when you grab an ultra large / is the thing that
is large ;).

Phil - I don't quite understand the operational use case: resizing the
root-fs is an in-OS operation, and snapshotting takes advantage of COW
semantics if qcow2 or similar backing storage is used. How does making
the size of the root exactly match that of the image make snapshotting
more efficient in that case? Or is it for deployments [there may be
some ;)] that don't use qcow2 style backing storage? Things like Ceph
mounted block devices will still be doing dirty block tracking, so
should be super efficient (and be able to do COW snapshots even more
efficiently in fact).

One thing I will note is that as a user, I *do not want* to specify
the root size in the images I build: thats what flavor is for, it's
how I define the runtime environment for my machine images; so - if we
do make flavor have more dynamic roots - I think it would be very
helpful to make sure that that can be overridden by the user [or that
the user has to opt into it]. (I realise that implies that
python-novaclient changes as well, not to mention documention).

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services



More information about the OpenStack-dev mailing list