[CRIU] [PATCH v4 03/17] regular files: protobuf "unreachable" field introduced

[Stanislav Kinsburskiy]

07.06.2016 14:24, Pavel Emelyanov пишет:
> On 06/06/2016 03:40 PM, Stanislav Kinsburskiy wrote:
>>
>> 06.06.2016 14:00, Pavel Emelyanov пишет:
>>> On 06/02/2016 03:03 PM, Stanislav Kinsburskiy wrote:
>>>> 02.06.2016 13:09, Pavel Emelyanov пишет:
>>>>> On 05/20/2016 02:37 PM, Stanislav Kinsburskiy wrote:
>>>>>> Will be used to determine whether this file have to be created prior to  open
>>>>>> on restore.
>>>>>>
>>>>>> Signed-off-by: Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>
>>>>>> ---
>>>>>>     criu/files-reg.c     |   10 ++++++++++
>>>>>>     images/regfile.proto |    1 +
>>>>>>     2 files changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/criu/files-reg.c b/criu/files-reg.c
>>>>>> index 73b2908..e3da972 100644
>>>>>> --- a/criu/files-reg.c
>>>>>> +++ b/criu/files-reg.c
>>>>>> @@ -1101,6 +1101,13 @@ static bool should_check_size(int flags)
>>>>>>     	return true;
>>>>>>     }
>>>>>>     
>>>>>> +static bool path_is_unreachable(struct fd_link *link, const struct fd_parms *parms)
>>>>>> +{
>>>>>> +	if (parms->fs_type == NFS_SUPER_MAGIC)
>>>>>> +		return true;
>>>>>> +	return false;
>>>>>> +}
>>>>>> +
>>>>>>     int dump_one_reg_file(int lfd, u32 id, const struct fd_parms *p)
>>>>>>     {
>>>>>>     	struct fd_link _link, *link;
>>>>>> @@ -1168,6 +1175,9 @@ ext:
>>>>>>     	rfe.has_mode = true;
>>>>>>     	rfe.mode = p->stat.st_mode;
>>>>>>     
>>>>>> +	rfe.has_unreachable	= true;
>>>>>> +	rfe.unreachable		= path_is_unreachable(link, p);
>>>>> Did you try to create remap entry for such files?
>>>>>
>>>> No, I didn't.
>>>> The reason is "unreachable" tag can be assigned to any file, including
>>>> remapped ones. IOW, it's another level of abstraction.
>>> Disagree. How would you assign "unreachable" to dead-pid remap?
>> Ok, not to _exactly_ any "remap" file.
>> But file can be only "unreachable", or both "unreachable" and
>> "unlinked", for example.
>> The alternative could be one more "remap" type, but then some file will
>> have multiple remap tags.
> I don't get why. If you have "just file" on NFS, it'll have one remap
> entry -- remap to SFS. If you have ghost file on NFS, then it will have
> a remap entry of ghost type, nothing more.

In case of unlinked NFS file I have to do some tricks with it to let 
SPFS manager know, that this file is "linked_remap", and it should 
perform special actions, when actual NFS is remapped.
IOW, I need to:

1) Mark this file (on SPFS mount) as unlinked, so I can distinguish it 
with others.
2) Add information about the link file to this SPFS file (I'm going to 
use extended attribute).

Then, with this information, I know, what should be done before actual 
replace once NFS is remounted.
That said, "just" and "unlinked" SPFS files creation differ.
Of course, two remap tags - SPFS and SPFS_UNLINKED  - can be added, if 
you prefer.

> -- Pavel