All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kaveh Razavi <kaveh@cs.vu.nl>
To: Alex Bligh <alex@alex.org.uk>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format
Date: Wed, 14 Aug 2013 16:26:05 +0200	[thread overview]
Message-ID: <520B937D.6060105@cs.vu.nl> (raw)
In-Reply-To: <F9F69094-D0AF-4A9A-B994-13FAD0075F00@alex.org.uk>

On 08/14/2013 03:50 PM, Alex Bligh wrote:
> Assuming the cache quota is not exhausted, how do you know how that
> a VM has finished 'creating' the cache? At any point it might
> read a bit more from the backing image.

I was assuming on shutdown.

> I'm wondering whether you could just use POSIX mandatory locking for
> this, i.e. open it exclusive and r/w until the 'finish point', then
> reopen RO, which would allow other VMs to share it. Any other VMs
> starting before the cache was populated simply fail to get the
> exclusive lock and go direct to the backing file.

This is a good idea, since it relaxes the requirement for releasing the
cache only on shutdown. I am not sure how the 'finish point' can be
recognized. Full cache quota is one obvious scenario, but I imagine most
VMs do/should not really read till that point (unless they are doing
something that should not be cached anyway - e.g. file-system check).
Another possibility is registering some sort of event to be executed
periodically (e.g. every 30 seconds), and if the cache is not modified
in a period, then that is the 'finish point'. I do not know how feasible
that is with the facilities that qemu provides.

Kaveh

  reply	other threads:[~2013-08-14 14:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 17:03 [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format Kaveh Razavi
2013-08-13 21:37 ` Eric Blake
2013-08-14 11:13   ` Kaveh Razavi
2013-08-13 22:53 ` Alex Bligh
2013-08-14 11:28   ` Kaveh Razavi
2013-08-14 11:52     ` Fam Zheng
2013-08-14 12:03       ` Alex Bligh
2013-08-14 15:58         ` Richard W.M. Jones
2013-08-15  0:53         ` Fam Zheng
2013-08-15  5:51           ` Alex Bligh
2013-08-14 11:57     ` Alex Bligh
2013-08-14 13:37       ` Kaveh Razavi
2013-08-13 23:16 ` Alex Bligh
2013-08-14 11:42   ` Kaveh Razavi
2013-08-14 12:02     ` Alex Bligh
2013-08-14 13:43       ` Kaveh Razavi
2013-08-14 13:50         ` Alex Bligh
2013-08-14 14:26           ` Kaveh Razavi [this message]
2013-08-14 15:02             ` Alex Bligh
2013-08-14 15:32             ` Kevin Wolf
2013-08-15  7:50               ` Wenchao Xia
2013-08-15  8:11               ` Stefan Hajnoczi
2013-08-14  9:29 ` Stefan Hajnoczi
2013-08-14 14:20   ` Kaveh Razavi
2013-08-15  8:32     ` Stefan Hajnoczi
2013-08-15 12:25       ` Kaveh Razavi

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=520B937D.6060105@cs.vu.nl \
    --to=kaveh@cs.vu.nl \
    --cc=alex@alex.org.uk \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.