[AdaAibaby]

Rebased follow-up to #3373, which @ryan-sana closed with: "please rebase onto current main and include a before/after measurement." This is that rebase, with the measurement.

Problem (still present on current main)

dispatchBufferSize is exactly 4 MiB — the maximum typical NBD data payload. But every request also carries a 28-byte header, so a max-size (4 MiB) write does not fit the buffer whole:

Read #1: [28B header][4MiB - 28B payload]   ← fills the 4 MiB buffer exactly
Read #2: [remaining 28B of payload]         ← one extra syscall

The September NBD dispatch refactor (ad11877aa, 0c21aa227) reshaped how commands are passed and added a sync.Pool, but left the buffer sizing untouched — the TODO acknowledging this is still verbatim on main:

// TODO: Look into optimizing the buffer reads by increasing the buffer size by 28 bytes,
// to account for a request that is 28 bytes of header + 4MB of data ...
dispatchBufferSize = 4 * 1024 * 1024

Fix

• Add nbdRequestHeaderSize = 28 and use it for the bare 28 literals in the dispatch loop (header completeness check, header slice, the three rp += 28).
• Widen dispatchBufferSize to 4*1024*1024 + nbdRequestHeaderSize so [28B header + 4 MiB payload] is taken in a single Read.
• Remove the resolved TODO and the now-inaccurate deadlock comment in the write path.

Before/after measurement (as requested)

Measured in-repo with a counting socket that feeds one 4 MiB write (header + full payload already buffered, as a busy kernel socket delivers it), counting the Read calls that returned payload bytes:

	buffer size	Read calls for one 4 MiB write
before (main)	4194304	2
after (this PR)	4194332	1

One syscall saved per max-size write. For I/O-heavy sandboxes doing large sequential block writes this is thousands of requests. Memory cost: 28 bytes per sandbox connection buffer.

Test

TestDispatchMaxSizeWriteSingleRead pins the behaviour: a 4 MiB write (header + full payload as one chunk) is consumed in exactly one Read, and the payload reaches the backend with the correct offset and full data integrity. Existing TestDispatchWriteZeroesReadLoopStall still passes; go build and go vet are clean.

Closes #3355. Supersedes #3373.

[ryan-sana]

This still does not say how frequent the two system call scenarios would be and what the cost of two system calls is and how it impacts the overall performance. Is the a numbers that backs this?

Most of the time, we work with larger values than 4MB. This is only a problem if we deal with very small blocks which isn't a general case.