Comment by Tepix

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.

Dunno about performance vs NFS, but I've stuffed an unaware OS onto ZVOL-over-iSCSI using a NIC with option ROM.

I kind of expect the performance is worse, but one neat thing is that iscsi is a block device, so you could run e.g. disk crypto, volume management or whatever on it. Not to mention any FS. And you don't need to deal with NFS or RPC.