From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 11 Date: Thu, 13 Jan 2011 18:12:04 +0200 Message-ID: <4D2F2454.4090305@redhat.com> References: <4D2C3B4D.2090709@redhat.com> <4D2C6C78.70606@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: quintela@redhat.com, Kevin Wolf , Chris Wright , qemu-devel@nongnu.org, kvm-devel To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14529 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933054Ab1AMQMQ (ORCPT ); Thu, 13 Jan 2011 11:12:16 -0500 In-Reply-To: <4D2C6C78.70606@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2011 04:43 PM, Anthony Liguori wrote: >> - invalidate all buffers for that block device on machine A after >> migration. >> * with NFS, just close + reopen the file (and pray that nobody else >> has it also opened) >> * with block devices: use BLKFLBLK ioctl, and pray that nobody >> else is >> using the device, that device is not a ramdisk, and some more >> things. To add injury to insult, you need to be root to be able >> to issue that ioctl (technically have CAP_SYS_ADMIN). > > > Why isn't fsync() enough for a block device? fsync() is fine on the outgoing side, but not on the incoming side. (the imcoming side might have valid buffers if it was the outgoing side on the previous migration, for example, or because of automatic probing) -- error compiling committee.c: too many arguments to function