Comment by rwmj

Requests and responses are pipelined so at least you're not serializing on round trips. However fundamentally if there is lots of latency, then you're going to be affected in some way. Usually we see problems where the OS accessing the remote drive times out which can sometimes be worked around by increasing timeouts, if you can work out how. (Latency is going to affect every block device protocol in about the same way)

You can actually see what happens quite easily if you've got an OS image handy. With a Fedora VM image:

  $ virt-builder fedora-42 --root-password=password:123456
  $ nbdkit file fedora-42.img --filter=delay rdelay=50ms \
           --run 'qemu-system-x86_64 -machine accel=kvm:tcg \
                     -cpu max -m 2048 \
                     -drive file="$uri",format=raw,if=virtio'

("$uri" expands to the NBD URI of the nbdkit server which qemu can parse natively)

Even that 1 second delay is painful since it turns out that booting is quite serialized. Edit: I turned down the latency to 50ms in the example which is a bit more realistic. Still painful.