[CRIU] [RFC] Migration of pipes with O_DIRECT flag.

[Stanislav Kinsburskiy]

11.12.2015 13:39, Pavel Emelyanov пишет:
> On 12/11/2015 03:29 PM, Stanislav Kinsburskiy wrote:
>>
>> 11.12.2015 13:22, Pavel Emelyanov пишет:
>>> On 12/11/2015 03:12 PM, Stanislav Kinsburskiy wrote:
>>>> Good day,
>>>>
>>>> MIgration of pipes with O_DIRECT is not supported yet.
>>> Ack. Not supported.
>>>
>>>> However, AutoFS control pipe is marked with O_DIRECT flag. Migration of
>>>> the content of control pipe is not supported, because it requires
>>>> migration of some kernel state.
>>>> What is even more important, is that original pipe, created my process
>>>> and provided to kernel, can doesn't have this flag: it's set by kernel
>>>> on AutoFS mount unconditionally.
>>>> Thus, it's enough just to remove check for O_DIRECT to allow AutoFS
>>>> migration.
>>>>
>>>> However, it's not a generic solution and such a pipe should me migrated
>>>> properly.
>>>> Major difference between ordinary pipe and O_DIRECT-one (within criu
>>>> scope), is that splice can't be used to dumping pipe data, because in
>>>> case of O_DIRECT flag pipe becomes a kind of queue, where individual
>>>> writes are not merged and have to be delivered to reader with it's
>>>> original size one per each read request.
>>> O'RLY? Can you point the place in the kernel that prevents us from tee-ing
>>> the pipe data as we do now?
>> I was talking about "splicing" pipe data to image, but not "teeing" pipe
>> data from one to another.
> We don't splice data from pipe to image, we tee data from pipe to criu pipe
> then splice it to image. If splice from pipe to image doesn't work it's OK,
> we can read it and write it. But of tee-ing doesn't work then we're in trouble.

I'm sorry, but I has never told, that tee'ing doesn't work. It works.
It works, and there is no trouble.

>> We can't use splice to write pipe data to image file, because packages
>> size information will be lost.
> That's OK, read data into buffer then write them into image.
>
>>>> Thus, migration of data from pipe with O_DIRECT have to be done differently.
>>>> Possible solutions are:
>>>> 1) Modify existent pipe entry image to contain a header with data size
>>>> after it. This will allow to fill image with array of header-data
>>>> objects. Not backward compatible.
>>> Pipe entry shouldn't be modified. There's a flags field that can just
>>> carry the O_DIRECT one. If you want more explicit thing add optional
>>> bool packetized field. Backward compatible.
>> O_DIRECT is not needed. It's in flags.
>>
>>> The better question is how to store packets in pipe-data images. The
>>> obvious solution is to keep several pipe_data_entry-s. At the first
>>> glace it would work.
>> It will. But we need to add sequence number to PipeDataEntry structure.
>> Is it ok add optional "sequence number" field to pipe_data_entry?
> What for? Why not restore them in the same sequence as they come from
> the image file?

I'm sorry, I understood you wrong. I thought, that you were telling 
about different files.
Now it's clear.

>>>> 2) Add one more field to pipe entry (some kind of sequence number) and
>>>> create a bunch of pipe entry files with equal id and other attributes,
>>>> but different sequence numbers. Since it's a new field in protobuf, is
>>>> should be backward compatible.
>>>> 3) Create another protobuf object for pipes with O_DIRECT.
>>>>
>>>> Maybe, there are more and better, than these.
>>>>
>>>> Would be great to hear any ideas.
>>>>
>>>> Sincerely,
>>>> Stanislav Kinsburskiy
>>>> _______________________________________________
>>>> CRIU mailing list
>>>> CRIU at openvz.org
>>>> https://lists.openvz.org/mailman/listinfo/criu
>>>> .
>>>>
>> .
>>