[CRIU] [RFC] Introduce v1.1 image format

[Pavel Emelyanov]

On 03/31/2015 04:37 PM, Ruslan Kuprieiev wrote:
> 
> On 03/31/2015 04:25 PM, Pavel Emelyanov wrote:
>> On 03/31/2015 04:21 PM, Ruslan Kuprieiev wrote:
>>> On 03/31/2015 04:10 PM, Pavel Emelyanov wrote:
>>>> On 03/31/2015 04:07 PM, Ruslan Kuprieiev wrote:
>>>>> On 03/31/2015 03:29 PM, Pavel Emelyanov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Right now we have too many criu-specific file types -- effectively
>>>>>> every new image file we add is a new "type", we invent a new magic
>>>>>> number for it and put only it into the header.
>>>>>>
>>>>>> One of the difficulty with this approach is that we can't nicely
>>>>>> teach the "file" utility to spot CRIU-specific files. Too many
>>>>>> magic should be added and we would have to add new magic numbers
>>>>>> for every new image type we introduce.
>>>>> But this patch leaves inventory.img intact, so "file" utility might as
>>>>> well just be taught to spot only inventory magic, because our images
>>>>> are spread across directory anyway.
>>>> Yes, and asking "file" for what the rest is would result in an unhelpful
>>>> answer -- "data" :)
>>> But we still have stats and irmap images, so "file" utility will say
>>> that it is "data".
>> Unless we add their magics into files's database.
> 
> Not sure that they have unique magic.

Checked, they do :)

>> The intention of this
>> set is to a) reduce the number of magics to add (will be 4) and b) to
>> make it possible to add more image files (if needed) without updating
>> the file's database.
> 
> But it might as well add some confusion -- we still require a directory
> to work with and the only file that actually matters is inventory.img.
> So one non-inventory file with criu magic doesn't worth nothing, but
> the end user might be confused with "file" utility telling that this 
> particular
> i.e. core-1234.img standalone file is "criu image file", and he might
> think that it is sufficient to work with.

CRIU will tell him that it's not.

>>>>> Do we really need these changes?
>>>> With this we will only need to add 4 magic-s in the file database.
>>>>
>>>>> This set also adds another level of confusing complexity to our images
>>>>> structure.
>>>>> Maybe we should rather suggest focusing on V2 images, to make them
>>>>> perfect and
>>>>> not create an intermediate version of non-backward compatible images?
>>>> V2 would be great, but they will be backward incompatible too :) So
>>>> from this perspective v1.1 is not worse.
>>> It is worse because it adds _new_ backward incompatible version with
>>> doubtful advantages, that could be just saved for later to be implemented
>>> in V2.
>> Yes, I agree. But converting from v1.1 to v1 can be done quite easily, we
>> don't need to patch CRIT heavily to achieve that.
> 
> True, I'm not scared with the required changes, but with the general 
> necessity of v1.1 with such a minor changes.

I tried to make v1.1 differ from v1 as little as possible. Right now we
(well, I) have no understanding of how v2 images should look like. We can
discuss it, but the current list of "what's bad" doesn't seem to be enough
for the v2. Even if we fix all the unused/misnamed problems this will be
the reason for v1.2 as the general idea of images wouldn't change.

-- Pavel