[CRIU] [PATCH 0/5] pipes: support for packetized mode (with O_DIRECT)

[Pavel Emelyanov]

On 12/21/2015 01:34 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 21.12.2015 11:33, Pavel Emelyanov пишет:
>> On 12/18/2015 05:25 PM, Stanislav Kinsburskiy wrote:
>>
>>>>> We can try to read many times with size, equal to pipe size.
>>>>> If we will be able to get more, than one buffer, then it's packetized pipe.
>>>>   From my perspective we don't have to distinguish packetized pipe from regular
>>>> when dumping queueu. Just write the data in the available chinks into the
>>>> pipe-date image and that's it.
>>> Packetized pipe is expected to be read by chunks sizeof PIPE_BUF (==
>>> PAGE_SIZE).
>>> In case of packetized pipe read will return only one buffer.
>>> In case of normal pipe it will return as many buffers, as fit into PIPE_BUF.
>>>
>>>>> If only one, then on restore:
>>>>> 1) If it's only read end without write, we don't care. We open a regular
>>>>> pipe and write this packet.
>>>>> 2) If it's a full pipe, then we a have a write end somewhere with
>>>>> O_DIRECT flag or without.
>>>>>
>>>>> Looks like this approach covers all the cases (except one very special,
>>>>> which we can not take into account).
>>>>>
>>>>> But it means, that we have to get rid of splice/vmsplice:
>>>>> 1) On dump, because we have to write all the packets individually.
>>>>> 2) On restore, because vmsplice doesn't work with packetized pipes.
>>>> BTW, I've glanced through the kernel and haven't found why splice doesn't
>>>> work for packetized pipes. Can you point out one?
>>> Sure.
>>> 1) Splice pipe to image file on dump. In this case we loose all the
>>> packets structure and having one single data chunk.
>> Why? Doesn't splice respect packetized buffers?
> 
> Imagine, that we have two packets.
> And you write them to a file with splice.
> How do you know the sizes of them after?

If splice respected packetized bufs then it would have proceeded one packet
at a call returning the number of bytes transferred. But it doesn't and
thus we're in trouble :(

-- Pavel