[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 2/7] block: add bdrv_get_format_allocated_size f

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH 2/7] block: add bdrv_get_format_allocated_size format interface
Date: Thu, 25 May 2017 21:07:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

25.05.2017 20:54, Eric Blake wrote:
On 05/25/2017 10:26 AM, Vladimir Sementsov-Ogievskiy wrote:
The function should return actually used by top-level format driver
s/actually/the allocation actually/

space (in it's .file). It differs from bdrv_get_allocated_file_size,
s/it's/its/ (remember, "it's" is only appropriate if "it is" can be used
in its place)

which returns allocated on fs file size.
s/allocated on fs file size/the disk usage of the underlying file/

So this is a measure of how many clusters a qcow2 image is currently
using (including metadata clusters, and regardless of whether those
clusters happen to point to a hole in the underlying protocol layer)?

Hmm, interesting remark. Now it is realized exactly as you write.. But this leads to the situation, when qcow2 allocates data amount > bdrv_getlength(bs->file->bs) and we will have negative size of unallocated area =). Denis what do you think? (Actually, we needed this feature for non-sparce file system and this question was not considered).

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
 block.c                   | 15 +++++++++++++++
 include/block/block.h     |  1 +
 include/block/block_int.h |  1 +
 3 files changed, 17 insertions(+)

diff --git a/block.c b/block.c
index ba22fc0dfb..6e1a435490 100644
--- a/block.c
+++ b/block.c
@@ -3407,6 +3407,21 @@ int64_t bdrv_get_allocated_file_size(BlockDriverState *bs)
+ * Actually used by top-level format driver space (in it's .file) in bytes

I think we can do better.  How about:

Return the amount of space allocated by the format driver (including
metadata) in bytes, even if some of that space currently maps to holes
in the underlying protocol file.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]