|
From: | Eric Blake |
Subject: | Re: [PATCH 5/8] block/file-posix: drop unallocated_blocks_are_zero |
Date: | Wed, 6 May 2020 16:41:48 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
raw_co_block_status() in block/file-posix.c never returns 0, so unallocated_blocks_are_zero is useless. Drop it.
As in 4/8, you are correct that it had no impact on block_status, but it did affect qemu-img convert. So again, removing the clients first makes this easier to justify as a cleanup patch.
That said...
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden> --- block/file-posix.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index 05e094be29..5c01735108 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -2878,9 +2878,6 @@ static int coroutine_fn raw_co_pwrite_zeroes(static int raw_get_info(BlockDriverState *bs, BlockDriverInfo *bdi){ - BDRVRawState *s = bs->opaque; - - bdi->unallocated_blocks_are_zero = s->discard_zeroes; return 0; }
the function now does nothing. Hmm - why does bdrv_get_info() return -ENOTSUP if the driver does not implement this function? Wouldn't it be better if the block layer could allow us to omit .bdrv_get_info and do the same thing, without us having to write a dummy function that does nothing but return 0? As separate patches, of course, as it would require changing several existing bdrv_get_info() callers to behave sanely when getting an all-0 success return where they now deal with an -ENOTSUP return.
So in the meantime, yes, we need this placeholder. Reviewed-by: Eric Blake <address@hidden> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |