From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQ4Ro-0008EA-4a for qemu-devel@nongnu.org; Sun, 12 Jul 2009 15:10:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQ4Rj-0008Dv-Lj for qemu-devel@nongnu.org; Sun, 12 Jul 2009 15:10:51 -0400 Received: from [199.232.76.173] (port=37509 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQ4Rj-0008Ds-CU for qemu-devel@nongnu.org; Sun, 12 Jul 2009 15:10:47 -0400 Received: from mail-yx0-f188.google.com ([209.85.210.188]:52755) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQ4Rj-0008AA-3H for qemu-devel@nongnu.org; Sun, 12 Jul 2009 15:10:47 -0400 Received: by yxe26 with SMTP id 26so3058035yxe.4 for ; Sun, 12 Jul 2009 12:10:45 -0700 (PDT) Message-ID: <4A5A3533.7040107@codemonkey.ws> Date: Sun, 12 Jul 2009 14:10:43 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state References: <1247140059-5034-1-git-send-email-pbonzini@redhat.com> <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> In-Reply-To: <4A59F1AC.9070401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , qemu-devel@nongnu.org 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