From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5GNi-0003PM-4k for qemu-devel@nongnu.org; Fri, 23 Apr 2010 06:45:10 -0400 Received: from [140.186.70.92] (port=57016 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5GNf-0003O7-Q4 for qemu-devel@nongnu.org; Fri, 23 Apr 2010 06:45:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5GNd-00050I-RY for qemu-devel@nongnu.org; Fri, 23 Apr 2010 06:45:07 -0400 Received: from isrv.corpit.ru ([81.13.33.159]:42983) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5GNd-0004zk-KA for qemu-devel@nongnu.org; Fri, 23 Apr 2010 06:45:05 -0400 Message-ID: <4BD17A2C.5050309@msgid.tls.msk.ru> Date: Fri, 23 Apr 2010 14:45:00 +0400 From: Michael Tokarev MIME-Version: 1.0 Subject: Re: [Qemu-devel] One more thing about block device locking References: <4BD12B10.1060304@msgid.tls.msk.ru> <20100423080025.GA1639@amd.home.annexia.org> In-Reply-To: <20100423080025.GA1639@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel Richard W.M. Jones wrote: > On Fri, Apr 23, 2010 at 09:07:28AM +0400, Michael Tokarev wrote: >> So we'll have to either >> trial and error, or open "normally", check >> if it's a block device and re-open with that >> flag set. > > Perhaps I'm missing something, but why can't you stat(2) the name > first to see if it's a block device (ie. S_ISBLK(st_mode)) then add > the O_EXCL flag or not as appropriate? Yes, that will work. Still, it appears to be linux-specific (the whole O_EXCL thing). > Anyway, the problem with this is it's not helpful (in fact: actively > bad) for libguestfs. We want to allow people to open existing devices > read-only, even if one qemu process has them open for writing. > Consider, for example, virt-df or virt-cat which allow you to read > information out from live VMs. Actually it IS quite helpful, to stop kvm from opening a filesystem mounted by the host or which is part of a raid array, or even if it's the system hard drive (*). And it looks like you didn't understand the semantics of O_EXCL: it works for only one open(), namely the one which has O_EXCL flag set, to mean "fail open if there are other users of the device at the moment". If a block device is open with O_EXCL flag, other processes can open it (without O_EXCL) as before, so no harm is done for virt-df or virt-cat which will still be able to do their tasks. > This is why we should have exclusive|shared modes for locking (or if > you prefer write|read -- it's the same thing with a different name > AFAICT). No, this is not the same thing. Explicit locking (fcntl/etc) works for plain files to prevent concurrent access by, say, two qemu processes (two guests) or the like. But O_EXCL on a block device works for host kernel too, which ignores file locking. One thing is to prevent two guests from opening the same device (or file) simultaneously. Another is to prevent corrupting a block device used by _host_ (and thus probably crashing host as well). That's why I said it's related but different topic, right at the beginning of my email. Both should be used as appropriate. I'll sum it all up when I'll finish with that long thread and after a bit more thinking :) Thanks! /mjt