0.3.7

Reading is five times faster.

Against a 10GbE target the volume read at 220 MB/s. It now reads at 1099 MB/s,
which is 94% of what the same link and target sustain when nothing is in the
way.

The cause was not the network and not the number of connections. macOS asks the
filesystem extension for one piece of the disk at a time and waits for each one
to come back before asking for the next, so the link sat idle for a full round
trip between every request — at a quarter of a millisecond each, that is most of
the time. The extension now fetches ahead of a sequential read, keeping enough
requests in flight to cover the wait.

It reads ahead only once two requests in a row have actually been consecutive.
Guessing after a single read would issue four requests nobody wanted and throw
them away, which is slower on a disk that has to seek, not faster. Any write
discards what was fetched, because data read before a write is wrong after it.

Verified rather than assumed: the same 256 MiB region checksums identically
before and after, and a 30-minute soak interleaving writes and seeks into
sequential reads checked 362,981 blocks individually and found no mismatch.

Writes are unchanged, and it is worth saying why. Every write is sent
write-through, because macOS never tells the extension when a filesystem wanted
its data made durable. Without that signal the only safe assumption is that it
always did. That costs about four and a half times the write speed and buys the
guarantee that an acknowledged write has actually landed — the right trade for a
disk on the other end of a network cable, and not one this release changes.

Also fixed: attaching could fail with "File system named iSCSI not found"
when more than one copy of the filesystem extension was registered, usually
after an update or from a disk image left mounted. The app now removes the extra
copies and retries by itself, instead of reporting the problem and asking you to
repair it from another screen.