After reading the message of commit 69f47505ee66 ("block: avoid
recursive block_status call if possible", 2019-06-04), I'm none the
wiser. But, I can at least confirm that all my qcow2 images are
pre-allocated, as a norm. I create them with the following command:
Perhaps this helps reproducing the issue. The commit message says,
"However, lseek is needed when we have metadata-preallocated image", so
that might be a special case that I've hit with some frequency.
I do have a vague suspicion that the following idea:
The idea is to compare allocation size in POV of filesystem with
allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
significantly lower, consider it as metadata-preallocation case.
is not robust enough. From the description, the "metadata-preallocation
case" appears to be determined with *heuristics*, but then again, "lseek
is needed when we have metadata-preallocated image". So if there is a
clear requirement to behave differently / particularly for
metadata-preallocated images, why is it safe to (basically) *guess*
whether a given image had its metadata pre-allocated?
... Not sure if it matters: the host filesystem holding my qcow2 images
is "ext4". Filesystem features (dumped with the fs being mounted r/w at
the moment): has_journal, ext_attr resize_inode, dir_index, filetype,
needs_recovery, extent, flex_bg, sparse_super, large_file, huge_file,
uninit_bg, dir_nlink, extra_isize. Filesystem flags:
signed_directory_hash.
After reading the message of commit 69f47505ee66 ("block: avoid
recursive block_status call if possible", 2019-06-04), I'm none the
wiser. But, I can at least confirm that all my qcow2 images are
pre-allocated, as a norm. I create them with the following command:
qemu-img create \ metadata \
-f qcow2 \
-o compat=1.1 \
-o cluster_size=65536 \
-o preallocation=
-o lazy_refcounts=on \
$FILENAME \
100G
Perhaps this helps reproducing the issue. The commit message says, preallocated image", so
"However, lseek is needed when we have metadata-
that might be a special case that I've hit with some frequency.
I do have a vague suspicion that the following idea:
The idea is to compare allocation size in POV of filesystem with preallocation case.
allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
significantly lower, consider it as metadata-
is not robust enough. From the description, the "metadata- preallocation preallocated image". So if there is a preallocated images, why is it safe to (basically) *guess*
case" appears to be determined with *heuristics*, but then again, "lseek
is needed when we have metadata-
clear requirement to behave differently / particularly for
metadata-
whether a given image had its metadata pre-allocated?
+ threshold = MAX(real_clusters * 10 / 9, real_clusters + 2);
Where do those constants come from?
... Not sure if it matters: the host filesystem holding my qcow2 images directory_ hash.
is "ext4". Filesystem features (dumped with the fs being mounted r/w at
the moment): has_journal, ext_attr resize_inode, dir_index, filetype,
needs_recovery, extent, flex_bg, sparse_super, large_file, huge_file,
uninit_bg, dir_nlink, extra_isize. Filesystem flags:
signed_
Thanks.