Re: rbd volume upgrades

[Alex Elder <elder@inktank.com>]

On 11/09/2012 01:44 PM, Yehuda Sadeh wrote:
> On Fri, Nov 9, 2012 at 11:30 AM, Josh Durgin <josh.durgin@inktank.com> wrote:
>> On 11/09/2012 11:08 AM, Yehuda Sadeh wrote:
. . .
>>>>
>>>> You need to export and then import the volume as format 2. Format 2 uses
>>>> different names for objects, so providing an 'upgrade' path would still
>>>> require copying all the data around.
>>>>
>>> Couldn't we just set a flag in the header specifying the object naming
>>> version, which would then only require updating the header?
>>>
>>> Yehuda
>>
>>
>> The header was separated from the id object to allow renames to work
>> while the image was in use or with cloning. The whole header format
>> changed and moved to a different object as a result. It would be
>> messy to implement this kind of upgrade, and doesn't provide much
>> benefit when there's an easy way to convert already. If someone really
>> wanted it, it could be implemented, but otherwise I don't think it's
>> worth adding. It would have to be added to the upcoming kernel
>> layering support too.
>>
> 
> The assumption is that when you upgrade you don't go back, so the fact
> that the header was separated from the id object doesn't change much.
> An upgrade process would be the same as creating a new v2 image,
> having object names (prefix?) that set as the original object names,
> and with a version field that specifies that these are a v1 names.
> 
> The problem that I see with converting v1 to v2 through copy is that
> (besides the cumbersome and potentially very long process) we will end
> up turning sparse data objects into fully written data objects, which
> will affect the data consumption.

I do think this lightning-fast, no-data-loss upgrade is a feature,
and I don't think it would be hard at all to implement.

					-Alex