All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] One more thing about block device locking
Date: Fri, 23 Apr 2010 09:07:28 +0400	[thread overview]
Message-ID: <4BD12B10.1060304@msgid.tls.msk.ru> (raw)

While I'm reviewing a thread about block device
locking, here's another data point which were
not touched before, as far as I remember.  It
is related.

What I'm talking is - when fsck/mkfs/... family
of programs are run against a mounted (or in use
by other means) device, they warn you about this,
or refuse to run.

This is done by opening the device in question
with O_EXCL flag - it is meaningless for an
existing block device so the meaning has been
overloaded on linux.

It is the _only_ way to ensure the device is
opened exclusively, and it covers such obscure
cases like opening whole disk when at least
one partition is in use by, say, an in-kernel
raid array or something like that.

So while it is the only way, it is also a
_reliable_ way too.

And while before, we were talked mostly about
inter-guest locking/protection, we also should
think about protecting guest and host from
each other.  O_EXCEL is exactly this case --
to ensure _host_ is not using the devie in
question when qemu is trying to open it.

Worth using IMHO :)  But it is a bit weird,
since it only works on linux (actually I've
no idea if it works on any other unix-like
system) and only on block devices, and only
at open(2) time.  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.  Both aren't exactly nice, but
should work.

I'll see what can be done there, but if
someone else who knows code better have
immediate ideas or implementation, welcome.

Thanks!

/mjt

             reply	other threads:[~2010-04-23  5:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23  5:07 Michael Tokarev [this message]
2010-04-23  8:00 ` [Qemu-devel] One more thing about block device locking Richard W.M. Jones
2010-04-23 10:45   ` Michael Tokarev
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=4BD12B10.1060304@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    /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.