From: Max Reitz <mreitz@redhat.com>
To: Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, jcody@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block/nfs: cache allocated filesize for read-only files
Date: Fri, 21 Aug 2015 09:46:46 -0700 [thread overview]
Message-ID: <55D755F6.2@redhat.com> (raw)
In-Reply-To: <1440143355-2918-1-git-send-email-pl@kamp.de>
On 2015-08-21 at 00:49, Peter Lieven wrote:
> If the file is readonly its not expected to grow so
> save the blocking call to nfs_fstat_async and use
> the value saved at connection time. Also important
> the monitor (and thus the main loop) will not hang
> if block device info is queried and the NFS share
> is unresponsive.
>
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---
> block/nfs.c | 6 ++++++
> 1 file changed, 6 insertions(+)
First, I don't like the idea of this patch very much, but since I've
never used qemu's native NFS client, it's not up to me to decide whether
it's worth it.
When it comes to breaking this, what comes to mind first is some
external program opening the image read-write outside of qemu and
writing to it. Maybe that's a case we generally don't want, but maybe
that's something some people do on purpose, knowing what they're doing
(with raw images), you never know.
Other than that, there's reopening. As far as I'm aware, qemu can reopen
a R/W image read-only, and if that happens, st_blocks may be stale.
Max
> diff --git a/block/nfs.c b/block/nfs.c
> index 02eb4e4..dc9ed21 100644
> --- a/block/nfs.c
> +++ b/block/nfs.c
> @@ -43,6 +43,7 @@ typedef struct NFSClient {
> int events;
> bool has_zero_init;
> AioContext *aio_context;
> + blkcnt_t st_blocks;
> } NFSClient;
>
> typedef struct NFSRPC {
> @@ -374,6 +375,7 @@ static int64_t nfs_client_open(NFSClient *client, const char *filename,
> }
>
> ret = DIV_ROUND_UP(st.st_size, BDRV_SECTOR_SIZE);
> + client->st_blocks = st.st_blocks;
> client->has_zero_init = S_ISREG(st.st_mode);
> goto out;
> fail:
> @@ -464,6 +466,10 @@ static int64_t nfs_get_allocated_file_size(BlockDriverState *bs)
> NFSRPC task = {0};
> struct stat st;
>
> + if (bdrv_is_read_only(bs)) {
> + return client->st_blocks * 512;
> + }
> +
> task.st = &st;
> if (nfs_fstat_async(client->context, client->fh, nfs_co_generic_cb,
> &task) != 0) {
>
next prev parent reply other threads:[~2015-08-21 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 7:49 [Qemu-devel] [PATCH] block/nfs: cache allocated filesize for read-only files Peter Lieven
2015-08-21 16:46 ` Max Reitz [this message]
2015-08-21 18:11 ` Peter Lieven
2015-08-21 18:23 ` Max Reitz
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=55D755F6.2@redhat.com \
--to=mreitz@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).