> Yeah, well, then you use qemu-img check to repair it. The refcount > structure is there to know which clusters are allocated, so we should > use it when we want to know that and not assume it's broken. If the > user thinks it may be broken, they are free to run qemu-img check to check.
Yea, it is right. It makes things easy. > Oh, I've just seen that your patch doesn't even get the allocated size, > it actually determines the highest allocated offset. Well, those are > two different things. You should not return this value via > qcow2_get_allocated_file_size(). I'm not sure where it should go > (probably wr_highest_offset?) and how it should be presented in > qemu-img, though. > > Also note that bdrv_get_allocated_file_size() is called by QMP's > query-named-block-nodes and query-block, both of which are online > synchronous functions. It should not take a long time, specifically it > should not scan the whole qcow2 file. Yes, My original idea was to get the highest allocated offset on the block device and regard it as currently max allocated size(ignore the hole lower than it). Through the discuss, I think it is better to count how many clusters with non-0 refcount as the real allocated size. I'll try to get a new version patch to implement this. On Fri, May 4, 2018 at 10:35 PM Max Reitz <mre...@redhat.com> wrote: > On 2018-05-03 15:06, 叶残风 wrote: > > > > Thanks for your review, Eric. > > Yes, the wr_highest_offset can tell the end offset at runtime, and > > write_threshold similar to it. But in my situation, I need to know > > the allocated end without a vm running. > > Oh, I've just seen that your patch doesn't even get the allocated size, > it actually determines the highest allocated offset. Well, those are > two different things. You should not return this value via > qcow2_get_allocated_file_size(). I'm not sure where it should go > (probably wr_highest_offset?) and how it should be presented in > qemu-img, though. > > Also note that bdrv_get_allocated_file_size() is called by QMP's > query-named-block-nodes and query-block, both of which are online > synchronous functions. It should not take a long time, specifically it > should not scan the whole qcow2 file. > > Max > >
