fast, checking the destination first is either a mere tradeoff in
commands (BLOCK_STATUS replacing WRITE_ZEROES when the destination is
already zero) or a pessimization (BLOCK_STATUS still has to be
-followed by WRITE_ZEROES). And if writing zeroes is slow, we have a
-speedup holes when BLOCK_STATUS itself is fast on pre-existing
-destination holes, but we encountered situations such as tmpfs that
-has a linear rather than constant-time lseek(SEEK_HOLE)
-implementation, where we ended up with quadratic behavior all due to
-BLOCK_STATUS calls. Thus, for now, qemu-img convert does not use
-BLOCK_STATUS, and as mentioned earlier, I used the noextents filter in
-my test case to ensure BLOCK_STATUS is not interfering with timing
-results.
+followed by WRITE_ZEROES). Conversely, if writing zeroes is slow, the
+penalty of the extra check when the destination is not a hole could be
+in the noise, but whether or not we have a definite speedup for
+avoiding WRITE_ZEROES depends on whether BLOCK_STATUS itself is fast -
+yet we encountered situations such as tmpfs that has a linear rather
+than constant-time lseek(SEEK_HOLE) implementation, where we ended up
+with quadratic behavior all due to BLOCK_STATUS calls. Thus, for now,
+qemu-img convert does not use BLOCK_STATUS.
* Heading: Pre-zeroing: a tale of two servers
- 4400- .term