From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQE8k-0004Tg-Jf for qemu-devel@nongnu.org; Mon, 13 Jul 2009 01:31:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQE8e-0004F3-T1 for qemu-devel@nongnu.org; Mon, 13 Jul 2009 01:31:49 -0400 Received: from [199.232.76.173] (port=43722 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQE8e-0004EE-M2 for qemu-devel@nongnu.org; Mon, 13 Jul 2009 01:31:44 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43970) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQE8e-0007gx-75 for qemu-devel@nongnu.org; Mon, 13 Jul 2009 01:31:44 -0400 Date: Mon, 13 Jul 2009 08:31:39 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state Message-ID: <20090713053139.GD28046@redhat.com> References: <1247140059-5034-3-git-send-email-pbonzini@redhat.com> <4A55F46F.6060705@codemonkey.ws> <4A55F510.5090801@redhat.com> <4A55F641.6000701@codemonkey.ws> <20090710231424.GD30322@shareable.org> <4A57E3AA.5020305@codemonkey.ws> <20090711014207.GM30322@shareable.org> <4A5958F8.3090306@codemonkey.ws> <4A59F1AC.9070401@redhat.com> <4A5A3533.7040107@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A5A3533.7040107@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Avi Kivity , qemu-devel@nongnu.org On Sun, Jul 12, 2009 at 02:10:43PM -0500, Anthony Liguori wrote: > 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? > With unreliable socket it doesn't matter what write() returns data may or may not reach the destination regardless, with reliable sockets write() succeeds only after data was acked by the receiver, but it still doesn't mean that data will be read from destination socket. -- Gleb.