From: Michael Tokarev <mjt@tls.msk.ru>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] One more thing about block device locking
Date: Fri, 23 Apr 2010 14:45:00 +0400 [thread overview]
Message-ID: <4BD17A2C.5050309@msgid.tls.msk.ru> (raw)
In-Reply-To: <20100423080025.GA1639@amd.home.annexia.org>
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
next prev parent reply other threads:[~2010-04-23 10:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 5:07 [Qemu-devel] One more thing about block device locking Michael Tokarev
2010-04-23 8:00 ` Richard W.M. Jones
2010-04-23 10:45 ` Michael Tokarev [this message]
2010-04-23 12:57 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BD17A2C.5050309@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.