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

[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?

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