From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Sf8-0003HK-Ev for qemu-devel@nongnu.org; Mon, 11 Apr 2011 21:45:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9Lhd-0001e6-Hn for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:19:10 -0400 Received: from verein.lst.de ([213.95.11.211]:44591 helo=newverein.lst.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Lhd-0001d0-9E for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:19:09 -0400 Date: Mon, 11 Apr 2011 20:19:08 +0200 From: Christoph Hellwig Message-ID: <20110411181908.GA9022@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Amit Shah , Kevin Wolf , Ryan Harper , qemu-devel , Markus Armbruster On Fri, Apr 08, 2011 at 12:33:27PM +0100, Stefan Hajnoczi wrote: > Amit and I were discussing the pros and cons of using O_EXCL to open > host CD-ROM devices on IRC but this discussion could benefit from more > input. > > Linux block devices (like /dev/sr0 CD-ROMs) can be opened with O_EXCL > and only one userspace process will succeed at a time. This prevents > programs from interfering with each other. The polling daemons, hald > and udisks, use O_EXCL and mount does too. > > Today QEMU does not use O_EXCL and will therefore access host CD-ROMs > while they are in use by other programs. This also means that > programs can be started on the host while QEMU is already running that > may interfere with the virtual machine's ability to access the CD-ROM > (for example by ejecting it). > > Therefore, it sounds reasonable to switch to O_EXCL to prevent > interfering with other programs and to prevent other programs > interfering with QEMU. This all boils down to whether qemu should allow concurrent access to image files of all sorts, and there are arguments both ways: pro: prevents corruption problems on disk images, notification issues on CDROMS, etc contra: makes clustering not work which means we need it configurable. I'd prefer to have the exclusion on by default, but people caring for backwards comptibility might argue the other way around. Either way it needs to be consistent for both devices and file images.