block/nfs: cache allocated filesize for read-only files
PATCH v2 1/1 block/nfs: cache allocated filesize for read-only files
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.
---v1->v2: update cache on reopen_prepare [Max]
block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
block/nfs.c +35 -0
@@ -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 ) {
@@ -484,6 +490,34 @@ static int nfs_file_truncate(BlockDriverState *bs, int64_t offset)return nfs_ftruncate (client->context, client->fh, offset); } +/* Note that this will not re-establish a connection with the NFS server +* - it is effectively a NOP. */ +static int nfs_reopen_prepare (BDRVReopenState *state, +BlockReopenQueue *queue,Error **errp) +{ +NFSClient *client = state->bs->opaque; +struct stat st; +int ret =0 ; + +if (state->flags &BDRV_O_RDWR &&bdrv_is_read_only (state->bs)) { +error_setg (errp,"Cannot open a read-only mount as read-write" ); +return -EACCES ; + } + +/* Update cache for read-only reopens */ +if (!(state->flags &BDRV_O_RDWR )) { + ret =nfs_fstat (client->context, client->fh, &st); +if (ret <0 ) { +error_setg (errp,"Failed to fstat file: %s" , +nfs_get_error (client->context)); +return ret; + } + client->st_blocks = st.st_blocks; + } + +return 0 ; +} +static BlockDriver bdrv_nfs = { .format_name ="nfs" , .protocol_name ="nfs" ,
@@ -499,6 +533,7 @@ static BlockDriver bdrv_nfs = { .bdrv_file_open = nfs_file_open, .bdrv_close = nfs_file_close, .bdrv_create = nfs_file_create, + .bdrv_reopen_prepare = nfs_reopen_prepare, .bdrv_co_readv = nfs_co_readv, .bdrv_co_writev = nfs_co_writev,
Signature · 1 line
1.9.1
Quoted 7 lines · Peter Lieven
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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.
Quoted 6 lines
Signed-off-by Peter Lieven <[email protected]>---
v1->v2: update cache onreopen_prepare[Max]block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 12 lines · Peter Lieven
Quoted 11 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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]>---
v1->v2: update cache onreopen_prepare[Max]
Quoted 6 lines
Quoted 2 lines
block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
actually a good point, maybe the cache should only be used if
!(bs->open_flags & BDRV_O_NOCACHE)
for my cdrom stuff this is still ok.
Peter
Quoted 15 lines · Peter Lieven
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 14 lines · Peter Lieven
Quoted 13 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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]>---
v1->v2: update cache onreopen_prepare[Max]block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
Quoted 7 lines
Quoted 4 lines
Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
actually a good point, maybe the cache should only be used if
!(bs->open_flags &
BDRV_O_NOCACHE)
Good enough a point to fix it? ;-)
Max
Quoted 20 lines · Max Reitz
Quoted 19 lines · Peter Lieven
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 18 lines · Peter Lieven
Quoted 7 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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.Quoted 6 lines
Signed-off-by Peter Lieven <[email protected]>---
v1->v2: update cache onreopen_prepare[Max]block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
Quoted 8 lines
Quoted 3 lines
actually a good point, maybe the cache should only be used if
!(bs->open_flags &
BDRV_O_NOCACHE)Good enough a point to fix it? ;-)
Max
It seems more inline with expected behavior, to add the cache checking in before using the size cache. Would you be opposed to a v3 with this check added in?
One other concern I have is similar to a concern Max raised earlier - about an external program modifying the raw image, while QEMU has it opened r/o. In particular, I wonder about an NFS server making an image either sparse / non-sparse. If it was exported read-only, it may be a valid assumption that this could be done safely, as it would not change the reported file size or contents, just the allocated size on disk.
Am 26.08.2015 um 17:31 schrieb Jeff Cody:
Quoted 23 lines · Max Reitz
Quoted 22 lines · Peter Lieven
Quoted 21 lines
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 12 lines · Peter Lieven
Quoted 11 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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]>---
v1->v2: update cache onreopen_prepare[Max]Quoted 6 lines
Quoted 2 lines
block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
actually a good point, maybe the cache should only be used if
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
!(bs->open_flags &
BDRV_O_NOCACHE)Good enough a point to fix it? ;-)
Max
It seems more inline with expected behavior, to add the cache checking in before using the size cache. Would you be opposed to a v3 with this check added in?
Of course, will send it tomorrow.
Quoted 8 lines
One other concern I have is similar to a concern Max raised earlier - about an external program modifying the raw image, while QEMU has it opened r/o. In particular, I wonder about an NFS server making an image either sparse / non-sparse. If it was exported read-only, it may be a valid assumption that this could be done safely, as it would not change the reported file size or contents, just the allocated size on disk.
This might be a use case. But if I allow caching the allocated filesize might not always be correct. This is even the case on a NFS share mounted through the kernel where some attributes a cached for some time.
Anyway, would it hurt here if the actual filesize was too small? In fact it was incorrect since libnfs support was added :-)
Peter
Quoted 44 lines · Peter Lieven
Am 26.08.2015 um 17:31 schrieb Jeff Cody:
Quoted 23 lines · Max Reitz
Quoted 22 lines · Peter Lieven
Quoted 21 lines
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 12 lines · Peter Lieven
Quoted 11 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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]>---
v1->v2: update cache onreopen_prepare[Max]Quoted 6 lines
Quoted 2 lines
block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
actually a good point, maybe the cache should only be used if
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
!(bs->open_flags &
BDRV_O_NOCACHE)Good enough a point to fix it? ;-)
Max
It seems more inline with expected behavior, to add the cache checking in before using the size cache. Would you be opposed to a v3 with this check added in?
Of course, will send it tomorrow.
Quoted 8 lines
One other concern I have is similar to a concern Max raised earlier - about an external program modifying the raw image, while QEMU has it opened r/o. In particular, I wonder about an NFS server making an image either sparse / non-sparse. If it was exported read-only, it may be a valid assumption that this could be done safely, as it would not change the reported file size or contents, just the allocated size on disk.
Quoted 7 lines
This might be a use case. But if I allow caching the allocated filesize might not always be correct. This is even the case on a NFS share mounted through the kernel where some attributes a cached for some time.
Anyway, would it hurt here if the actual filesize was too small? In fact it was incorrect since libnfs support was added :-)
Yeah, I'm not sure what harm it would cause in practice. It is a fairly edge use case to begin with, and a relatively benign side affect (especially since you added reopen() support).
With the cache flag checking, I am comfortable adding my r-b.
Jeff
Quoted 53 lines · Jeff Cody
Quoted 44 lines · Peter Lieven
Am 26.08.2015 um 17:31 schrieb Jeff Cody:
Quoted 23 lines · Max Reitz
Quoted 22 lines · Peter Lieven
Quoted 21 lines
Am 24.08.2015 um 20:39 schrieb Max Reitz:
Quoted 12 lines · Peter Lieven
Quoted 11 lines
If the file is readonly its not expected to grow so save the blocking call to
nfs_fstat_asyncand 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]>---
v1->v2: update cache onreopen_prepare[Max]Quoted 6 lines
Quoted 2 lines
block/nfs.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)Reviewed-by Max Reitz <[email protected]>I hope you're ready for the "Stale actual-size value with cache=direct,read-only=on,format=raw files on NFS" reports. :-)
actually a good point, maybe the cache should only be used if
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
!(bs->open_flags &
BDRV_O_NOCACHE)Good enough a point to fix it? ;-)
Max
It seems more inline with expected behavior, to add the cache checking in before using the size cache. Would you be opposed to a v3 with this check added in?
Of course, will send it tomorrow.
Quoted 8 lines
One other concern I have is similar to a concern Max raised earlier - about an external program modifying the raw image, while QEMU has it opened r/o. In particular, I wonder about an NFS server making an image either sparse / non-sparse. If it was exported read-only, it may be a valid assumption that this could be done safely, as it would not change the reported file size or contents, just the allocated size on disk.
Quoted 7 lines
This might be a use case. But if I allow caching the allocated filesize might not always be correct. This is even the case on a NFS share mounted through the kernel where some attributes a cached for some time.
Anyway, would it hurt here if the actual filesize was too small? In fact it was incorrect since libnfs support was added :-)
Quoted 5 lines
Yeah, I'm not sure what harm it would cause in practice. It is a fairly edge use case to begin with, and a relatively benign side affect (especially since you added
reopen()support).With the cache flag checking, I am comfortable adding my r-b.
I don't remember QEMU's behavior on an LVM volume (which can be resized underneath QEMU but isn't expected to grow or shrink under normal operation).
The same semantics should probably be used here.
Stefan