[openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

Day, Phil philip.day at hp.com
Mon Dec 30 19:05:17 UTC 2013


Hi, so it seems we were saying the same thing - new vms get a shared "blank" (empty) file system,  not blank disc.  How big a problem it is that in many cases this will be the already created ext3 disk and not ext4 depends I guess on how important consistency is to you (to me its pretty important).  Either way the change as it stands wont give all new vms an ext4 fs as intended,  so its flawed in that regard.

Like you I was thinking that we may have to move away from "default" being in the file name to fix this.

I don't think the cache clean up code ever removes the ephemeral backing files though at the moment.

Phil

Sent from Samsung Mobile



-------- Original message --------
From: Pádraig Brady <P at draigBrady.com>
Date:
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>,"Day, Phil" <philip.day at hp.com>
Subject: Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4


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.



More information about the OpenStack-dev mailing list