[CRIU] [PATCH v4 04/17] protobuf: autofs mount entry introduced
Stanislav Kinsburskiy
skinsbursky at odin.com
Tue Jan 19 08:00:25 PST 2016
19.01.2016 16:46, Pavel Emelyanov пишет:
>>>> +}
>>>> +
>>>> message mnt_entry {
>>>> required uint32 fstype = 1;
>>>> required uint32 mnt_id = 2;
>>>> @@ -45,4 +59,6 @@ message mnt_entry {
>>>>
>>>> optional bool deleted = 16;
>>>> optional uint32 sb_flags = 17 [(criu).hex = true];
>>>> +
>>>> + optional autofs_entry autofs = 18;
>>> Plz, describe how this field will be managed for mountpoints
>>> sharing the same superblock (e.g. mount and bind-mount of it)?
>> All of them will have the same data here. I.e. it's duplicated.
> Too bad :(
>
> I start thinking that my proposal to have fs-specific field on mount entry
> was wrong, since the mount entry is _a_ _mount_ _entry_, not a super block
> one. So for writing super block data we should introduce another image(s).
Frankly, this sounds like a rework of existent code base. If you start
think so, then, probably, in makes sense to go even further.
Mount_info already has a lot of duplicated information (even superblock
related fields).
From my pow, introducing a superblock structure is an overkill,
especially because CRIU doesn't operate on this level, while introducing
only one mount object per mount with a list of paths to bind to might
have some sense. But I don't know, how it correlates with mount
namespaces code though.
And, frankly, this is not the right moment to optimize such things. I
doesn't look like sufficient solution is easily reachable.
Maybe it makes sense to wait till NFS in also in place, and then
optimize the whole mounts migration basing on this experince.
> -- Pavel
More information about the CRIU
mailing list