[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] block/nfs: cache allocated filesize for read-on
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [PATCH] block/nfs: cache allocated filesize for read-only files |
Date: |
Fri, 21 Aug 2015 20:11:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Am 21.08.2015 um 18:46 schrieb Max Reitz:
> 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 <address@hidden>
>> ---
>> 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.
I am trying to solve that a stale NFS Server with a CDROM ISO on it can hang
Qemus main loop. One of the things that happens is that
you query "info block" in hmp or "query-block" via QMP and indirectly call
bdrv_get_allocated_file_size and bang, Qemu hangs. Also I don't
know if its worth to issue an RPC call for each executing of info block.
>
> 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.
I would consider this bad behaviour. However, allocated file size shouldn't
matter for raw images. If you resize the image from external you have to call
bdrv_truncate anyway to make Qemu aware
of that change.
>
> 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.
Thats a valid point. But it can be solved be implementing .bdrv_reopen_prepare
and update st_blocks there.
Thanks for you thoughts,
Peter