[CRIU] [RFC] Introduce v1.1 image format
Ruslan Kuprieiev
kupruser at gmail.com
Tue Mar 31 06:21:34 PDT 2015
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".
>> 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.
> -- Pavel
>
More information about the CRIU
mailing list