[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