[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v4 0/3] qemu-img check: format allocation info

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v4 0/3] qemu-img check: format allocation info
Date: Mon, 31 Jul 2017 18:43:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

31.07.2017 18:14, Eric Blake wrote:
On 07/29/2017 11:41 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all.

See 01 patch for the doc.

Question to discuss.
If I understand correctly get_block_status flags allocated, zero, and data
actually provide 5 possible combinations, which I combine into three.
There are actually 8 possible bit combinations, but you are right that
some of them are in practice impossible (since the allocated bit can
only be set in cases where the underlying driver set the data or zero bit).

allocated data zero
1         1    1    \__ data
This one is interesting - it means we know the contents read as zero,
but that it occupies space on the disk instead of being a hole;
reporting it as zero may make it easier to punch a hole.

1         1    0    /
Yes, definitely data, and no clue if it can be turned into a hole.

1         0    1    \__ zero
0         0    1    /
Yes, definitely zero.  (The former happens when a format layer directly
reports that the current layer reads as zero; the latter is possible
when a format layer doesn't have an allocation, but where we know
unallocated clusters read as zero, perhaps because there is no backing
file to further fall back to).

0         0    0    ___ discarded
Could also mean hasn't been touched yet (discarded sort of implies that
it has been touched at some point in the past)

last time I don't like it too. What about renaming it to just 'unallocated'?

The other bit patterns:

   0         1    0    - not possible: if a driver sets data, then the
block layer sets allocated

   0         1    1    - ditto
   1         0    0    - not possible: nothing sets the allocated bit in

This division looks not bad, but it is not the only one possible.
Separating data is really useful - it shows leaked clusters..
So the question is, don't we want to adjust the division?
I'm ok with the current one.

Best regards,

reply via email to

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