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

[Stanislav Kinsburskiу]

15 дек. 2015 г. 9:16 PM пользователь Pavel Emelyanov <xemul at parallels.com> написал:
>
> On 12/15/2015 11:11 PM, Stanislav Kinsburskiу wrote: 
> > 
> > 15 дек. 2015 г. 20:39 пользователь Pavel Emelyanov <xemul at parallels.com> написал: 
> >> 
> >> On 12/15/2015 08:55 PM, Stanislav Kinsburskiy wrote: 
> >>> There is something, I would like to discuss. 
> >>> Currently, only _write_ end as O_DIRECT flag. Criu uses _read_ end to 
> >>> tee data from it to local pipe. There is a problem, _how_ to discover, 
> >>> whether pipe is "packetized" or not. This knowledge is required, because 
> >>> splice() can be used only for non-packetized pipes (otherwise all 
> >>> individual packets will be merged to one in image file). 
> >>> 
> >>> But, I'm afraid, it's not enough... Because "packetized" pipe mode is 
> >>> not something stable, because it's represented by file flag. Regular 
> >>> pipe can be reopened with O_DIRECT flag or vise versa, but packets, 
> >>> which were sent, _when_ pipe was _"packetized"_, are already _marked_ as 
> >>> _"non-mergeable"_. 
> >>> So, probably, in generic case, it's not enough to create a pipe on 
> >>> restore, fill it with data and set correct file flags, because pipe can 
> >>> contain both "packets" and regular content. 
> >> 
> >> I wouldn't say it's typical use for pipes. Can we support only those 
> >> that have all ends in the same state -- either packetized or not? 
> >> 
> > 
> > No, it's not a typical way for sure. 
> > But I don't know yet, how to distinguish... 
> > One of major problems, as I mentioned, is that only _write_ end is marked with O_DIRECT. 
> > What to do, if we have a bunch of pipe ends (inherited, whatever)? 
> > Should we gather them somehow on dump and check, that all write ends are either with O_DIRECT or without? 
>
> Yes. 
>

Ok... This is crap, but, probably, the best we can do without being involved into a long fight for making this mode solid...
And, unfortunatelly, all this will work only, if issues I tried to fix with the patches I sent today, are fixed some way.

> > Probably, it makes sense to send a patch, which also marks read end with O_DIRECT on creation? 
>
> No, read-end seems to be unaffected by this. 
>
> > If it will be aacepted, then, at least, we can put a restriction, that we treat pipes mode as 
> > static (either always paketized of never packetized). What do you think? 
> > Or we need some way to ask, which packet type is the next in the queue... This will allow to 
> > handle any pipes, but then we can't use splice and have to change pipe type during its content restore if it contains different buffers. 
> > 
> > But frankly, from my POW, packet pipe design was broken from early beginning. 
> > Man page says, that if pipe is packetized, reader can be sure, that incomming packet won't be 
> > bigger than page size. I can easily violate this rule by reopening pipe without O_DIRECT, and 
> > writing more than page into it... 
>
> Sure. As glibc former maintainer once said: "giving people a rope to shoot themselves 
> is a Unix tradition". 
>

Yep. But I'm quite surprised, because of the author of this feature...
Interesting, but this mode was introduced precisely for AutoFS. 

> -- Pavel