Re: [Qemu-devel] migration: adding migration to/from a file (v2)

["M. Warner Losh" <imp@bsdimp.com>]

In message: <499DF276.4080305@codemonkey.ws>
            Anthony Liguori <anthony@codemonkey.ws> writes:
: M. Warner Losh wrote:
: > In message: <20090219202849.GE22319@shareable.org>
: >             Jamie Lokier <jamie@shareable.org> writes:
: > : Anthony Liguori wrote:
: > : > >Sure looks like a bug.
: > : > I wish!  It's Unix suckiness.
: > : 
: > : Windows is the same.
: > : It's a more of a conceptual problem than it looks, not merely an API bug.
: > : 
: > : It comes down to "what would 'readable' and 'writable' mean on a file?".
: >
: > "Would a read or write operation block?" is a better way to look at
: > the interface that select() or poll() provides.  For a regular file,
: > the answer is "no" since the writes are so fast and often
: > asynchronous...
: >   
: 
: Except when they aren't..

Right.  That bit was added later, I think...  My note was more of an
explanation of how we got here, not that it was perfect and a good
thing..

: The real issue is that read/write offers streaming semantics, not random 
: access.  You cannot guarantee that a read is going to complete unless 
: you do read ahead.  So the semantics would be something like pread(fd, 
: buf, X) = EAGAIN (kernel starts the operation for X), later, pread(fd, 
: buf, X) = OK.  Sort of a weird interface.
: 
: For write, it's even more bizarre because you can't "write-ahead".  If 
: you're dealing with O_SYNC or O_DIRECT, there's simply no semantic that 
: makes sense.
: 
: So fundamentally, read/write is a bad interface for random IO.

Also agreed.

: Regards,
: 
: Anthony Liguori
: 
: > Warner
: >
: >
: >   
: 
: 
: 
: