Open Stack

On 12/30/2013 12:39 AM, Pádraig Brady wrote:
> On 12/29/2013 08:12 AM, Day, Phil wrote:
>> Hi Folks,
>>
>> As highlighted in the thread “minimal review period for functional changes” I’d like to propose that change is https://review.openstack.org/#/c/63209/ is reverted because:
>>
>> -          It causes inconsistent behaviour in the system, as any existing "default" backing files will have ext3 in them, so a VM will now get either ext3 or 3ext4 depending on whether the host they get created on already has a backing file of the required size or not.   I don't think the existing design ever considered the default FS changing - maybe we shouldn’t have files that include "default" as the file system type if it can change over time, and the name should always reflect the FS type.
> 
> I'm not sure this is a practical issue since ephemeral storage is built up from blank by each instance

Phil> Maybe it varies by hypervisor; my understanding is that at least in libvirt the ephemeral disks are cow layers on a shared common backing file that has the file system in it.
Phil> The naming convention includes the size and fs type or "default" and is only created once per size-fs combination.
Phil> So this is a real issue - I think that maybe the eventual change to ext4 need to be combined withoving away from "default"  in the file name.

Right, what I meant by each instance building ephemeral up from blank each time,
is that each instance will go from either a blank ext3 or blank ext4 each time,
so if they support ext4 then there should be no practical issue. Now agreed there
is a consistency issue, which could have performance consistency issues for example,
so it's not ideal.

To be complete, for the libvirt case we don't even use these persistent backing files
for ephemeral disks if use_cow_images=False or with LVM backing.

To be most general and avoid this consistency issue, I suppose we could change the
name format for these cached CoW base images from ephemeral_10_default, ephemeral_20_linux etc.
to 'ephemeral_20_' + md5(mkfs_command)[:7]
That would impose a performance hit at first boot with this new logic,
and we'd have to double check that the cache cleaning logic would
handle removing unused older format images.
Alternatively we might just document this issue and put the onus on
users to clean these cached ephemeral disk on upgrade
(the commit is already tagged as DocImpact).

thanks,
Pádraig.