On 1/11/19 10:02 AM, Eric Blake wrote: > Even a dumb most-recent use cache will speed this up: both the second > and third queries above can be avoided because we know that both 0x40000 > and 0x30000 the second query at 0x40000 can be skipped (0x40000 is > between our most recent lseek at 0x20000 and hole at 0x10000) > > Make the cache slightly larger, or use a bitmap with 2 bits per cluster > (tracking unknown, known-data, known-hole), with proper flushing of the > cache as we write to the image, or whatever, and we should automatically > get some performance improvements by using fewer lseek() anywhere that > we remember what previous lseek() already told us, with no knobs needed.
In fact, block/iscsi.c has such a cache; look at iscsi_allocmap_update() and friends; maybe we should generalize that code in order to reuse the same concepts in file-posix.c. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
