Am 24.01.2019 um 16:56 hat Eric Blake geschrieben: > On 1/24/19 8:17 AM, Kevin Wolf wrote: > > Depending on the exact image layout and the storage backend (tmpfs is > > konwn to have very slow SEEK_HOLE/SEEK_DATA), caching lseek results can > > save us a lot of time e.g. during a mirror block job or qemu-img convert > > with a fragmented source image (.bdrv_co_block_status on the protocol > > layer can be called for every single cluster in the extreme case). > > > > We may only cache data regions because of possible concurrent writers. > > This means that we can later treat a recently punched hole as data, but > > this is safe. We can't cache holes because then we might treat recently > > written data as holes, which can cause corruption. > > gluster copies heavily from file-posix's implementation; should it also > copy this cache of known-data? Should NBD also cache known-data when > NBD_CMD_BLOCK_STATUS is available?
This almost suggests that we should do the caching in generic block layer code. It would require that we can return a *pnum from the block driver that is larger than the requested bytes from, but it looks like raw_co_block_status() already handles this? We just don't seem to do this yet in the block drivers. If we want to cache for all drivers, however, the question is whether there are drivers that can transition a block from data to hole without a discard operation, so that we would have to invalidate the cache in more places. One thing that comes to mind is loading an internal snapshot for qcow2. Or maybe we need to make this opt-in for drivers, with a bool flag in BlockDriver? Kevin
signature.asc
Description: PGP signature
