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 <[email protected]>
---
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) {
