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

[Stanislav Kinsburskiy]

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 can't use splice to write pipe data to image file, because packages 
size information will be lost.

>> 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?

>> 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
>> .
>>