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

Stanislav Kinsburskiy skinsbursky at odin.com
Mon Dec 21 02:56:20 PST 2015



21.12.2015 11:45, 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 :(

Unfortunately, yes, we are in trouble. Splice doesn't respecting this.
It iterates over the buffers and write them one by one.



More information about the CRIU mailing list