Open Stack

On Wed, 5 Jun 2013, Parthipan, Loganathan (Cloud Services) wrote:

>
> >
> > Hi Scott,
> >
> > > The other thing I don't like about it is that, currently (at least in
> > > libvirt driver), ephemeral disks are cached.  This is because
> > ephemeral
> > > disks are attached with a filesystem already created on them. That
> > > allows the user to immediately use the disk without having to do
> > mkfs,
> > > and the caching of that image saves the host from having to do it on
> > > every instance launch.
> > >
> > > If you use:
> > >  ephemeral_gb = (flavor.root_gb + flavor.ephemeral_gb) -
> > > instance.root_gb and instance.root_gb all of a sudden varies greatly
> > > amoung instances, then the host will be creating ephemeral images
> > (and
> > > mkfs'ing them) possibly for every instance.
> >
> > It is my understanding that the filesystem is created on the COW layer
> > of the ephemeral disks (disk.local) and not on the backing file itself
> > by cloudinit or similar software after instance startup. I'm not sure
> > if there's any data on the backing file itself.
> >
>
> You're right. A filesystem is indeed created on the backing file. Sorry :)

fwiw, it would be possible to have the host only attach a blank drive to
the instances as ephemeral0.  However, then every guest OS that wanted to
use this would have to do 'mkfs /dev/vdb'.  That would end up
 a.) slowing down the instance's ability to use that device
 b.) creating another flurry of IO on instance boot as the instances
     'mkfs /dev/vdb'

The host creates it and mkfs's is a substantial optimization in both
feature and IO.

Additionally, if you changed that now, you'd be breaking guest
expectation, which should be a very big no-no.

Just a quick test for some information, mkfs.ext3 (1.42.5-1ubuntu4):
 openstack guest 20G /dev/vdb took 4.624s real 0m0.884s sys
 ec2 guest 160G /dev/xvda2: 1m14.649s real, 0m2.072s sys.

(in both cases, subsequent runs are faster, possibly because the backing
disk is much less sparse at that point).

Scott