25.01.2019 17:21, Vladimir Sementsov-Ogievskiy wrote: > drv_co_block_status digs bs->file for additional, more accurate search > for hole inside region, reported as DATA by bs since 5daa74a6ebc. > > This accuracy is not free: assume we have qcow2 disk. Actually, qcow2 > knows, where are holes and where is data. But every block_status > request calls lseek additionally. Assume a big disk, full of > data, in any iterative copying block job (or img convert) we'll call > lseek(HOLE) on every iteration, and each of these lseeks will have to > iterate through all metadata up to the end of file. It's obviously > ineffective behavior. And for many scenarios we don't need this lseek > at all. > > However, lseek is needed when we have metadata-preallocated image. > > So, let's detect metadata-preallocation case and don't dig qcow2's > protocol file in other cases. > > 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. > > Suggested-by: Denis V. Lunev <d...@openvz.org> > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> > --- > > Hi! > > So, to continue talk about lseek/no lseek when qcow2 block_status reports > DATA. > > Results on tmpfs: > cached is lseek cache by Kevin > detect is this patch > no lseek is just remove block_status query on bs->file->bs in > bdrv_co_block_status > > +---------------------+--------+--------+--------+----------+ > | | master | cached | detect | no lseek | > +---------------------+--------+--------+--------+----------+ > | test.qcow2 | 80 | 40 | 0.169 | 0.162 | > +---------------------+--------+--------+--------+----------+ > | test_forward.qcow2 | 79 | 0.171 | 0.169 | 0.163 | > +---------------------+--------+--------+--------+----------+ > | test_prealloc.qcow2 | 0.054 | 0.053 | 0.055 | 0.263 | > +---------------------+--------+--------+--------+----------+
Forgot to say, tests by Kevin from branch https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg05463.html Hmm. Don't we have something like tests/qemu-iotests, but for performance? So, all these small pretty tests we have in mailing list may go as git patches? -- Best regards, Vladimir
