[CRIU] [PATCH v4 04/17] protobuf: autofs mount entry introduced

[Stanislav Kinsburskiy]

19.01.2016 17:58, Pavel Emelyanov пишет:
> On 01/19/2016 07:00 PM, Stanislav Kinsburskiy wrote:
>>
>> 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.
> Just one more path (with aufs sb images) and fix for dump/restore code
> not to get AutofsEntry from MntEntry, but read one from new image.
>
>> 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).
> What are these?

Looks like these (maybe more):
sb_flags, fstype, source, options, s_dev.

For instance, most of the fields are the same in example below:

89 86 0:47 / /proc/sys/fs/binfmt_misc rw,relatime shared:64 - 
binfmt_misc binfmt_misc rw
90 44 0:47 / /mnt                                rw,relatime shared:64 - 
binfmt_misc binfmt_misc rw

where /mnt is a bin-mount of /proc/sys/fs/binfmt_misc.

>>   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
>> .
>>