Just a question to understand the problem: Would use cases like file-backed VMs fall under this? They can be reasonably parallel (but using distinct threads, not processes, as far as the host OS is concerned) and work all on the same (image) file. Or are the access patterns "wrong" and don't trigger this bug?
I am pretty sure not. For zvols, I don't see anything calling the affected function. For file-backed, I don't think the access pattern works. First, there's almost going to be a block cache and a filesystem in the guest OS, so the transition from hole->data actually means the filesystem allocated that some part of the block device (or file masquerading as one) and wrote to it. If so, it already knows if there's data there or not - it doesn't need to seek! And any callers above the OS seeking/reading at the same moment as the write are going to be served from cache, not from "storage". And all this is assuming that the VM even has a reason to call lseek(), which seems strange, as it not actually "is there something here", but, "find the next thing after this position", and that could require a lot of disk access to discover.
