From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSqyt-00023P-I5 for qemu-devel@nongnu.org; Fri, 21 Aug 2015 14:24:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSqys-0001in-BU for qemu-devel@nongnu.org; Fri, 21 Aug 2015 14:23:59 -0400 References: <1440143355-2918-1-git-send-email-pl@kamp.de> <55D755F6.2@redhat.com> <55D769C4.4010205@kamp.de> From: Max Reitz Message-ID: <55D76CB8.4050001@redhat.com> Date: Fri, 21 Aug 2015 11:23:52 -0700 MIME-Version: 1.0 In-Reply-To: <55D769C4.4010205@kamp.de> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block/nfs: cache allocated filesize for read-only files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu-devel@nongnu.org, qemu-block@nongnu.org Cc: kwolf@redhat.com, jcody@redhat.com On 2015-08-21 at 11:11, Peter Lieven wrote: > 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 >>> --- >>> 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. OK. >> >> 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. I don't know about NFS, but for other file systems it does. $ ./qemu-img create -f raw test.raw 1G $ ./qemu-io -c 'write 1023M 1M' test.raw $ ./qemu-img info test.raw ... virtual size: 1.0G (1073741824 bytes) disk size: 1.0M I do consider it bad behavior, too, but with raw images it should actually be valid for some use cases. > 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. Right. Since the allocated size is not that important of an information, generally, I think I'd be fine with breaking the use case of writing to an image with an external tool while qemu is using that image read-only, as long as reopening works. > Thanks for you thoughts, Thanks for your patch. :-) Max