Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> On 07/12/2009 06:31 AM, Anthony Liguori wrote:
>> Jamie Lokier wrote:
>>> If you get an error during the last write(), I wouldn't trust that to
>>> mean the recipient will definitely not see the data you wrote.  (Enjoy
>>> the double negative).  It's another variation of the handshake
>>> uncertainty, this time reflected in what write() should report when
>>> it's uncertain about a network transmission.  If it reports an error
>>> when it's uncertain, then you can't trust that a write() error means
>>> the data was not written, only that a problem was detected.
>>
>> I think you're stretching here.  If it really were the case that 
>> write() could actually result in data being sent out the wire and yet 
>> still returning an error, it would make all error handling in Unix 
>> unmanagable.  I can't believe this is possible in Linux and without 
>> an actual counter-example, I'm inclined to believe the same is true 
>> for every other OS out there.
>
> It's actually a common scenario for block devices.  I don't know about 
> networking, but for disks a write can be completed and then report an 
> error if the cable or power was disconnected before the acknowledge 
> could arrive.

Is it common that a disk cable is yanked out before the ack arrives?  
Are their gremlins in your servers :-)

> It could conceivably happen with networking if the device reports an 
> error when it isn't sure if the data was sent out or not (but it 
> actually was), or if some path after the transmission required a 
> memory allocation, which failed.

But does this actually happen or is this all theoretical?

Regards,

Anthony Liguori