On Jun 15 2022, "Richard W.M. Jones" <rjones@redhat.com> wrote:
I think we could set this to MIN (32M, NBD maximum block size constraint), converting the result to sectors.
I don't think that's right. Rather, it should be NBD's preferred block size.
Setting this to the preferred block size means that NBD requests will be this large whenever there are enough sequential dirty pages, and that no requests will ever be larger than this. I think this is exactly what the NBD server would like to have.
This kernel setting limits the maximum request size on the queue.
Right. But why not limit it to the *preferred* blocksize of the NBD server? The kernel obviously does not care, and the NBD server obviously prefers this blocksize over the maximum block size.
In my testing reading and writing files with the default [above] the kernel never got anywhere near sending multi-megabyte requests.
Well, yes, but that shouldn't affect which value we should use, I think.
Unrelated to the proposed changes (all of which I think are technically correct), I am wondering if this will have much practical benefits. As far as I can tell, the kernel currently aligns NBD requests to the logical/physical block size rather than the size of the NBD request. Are there NBD servers that would benefit from the kernel honoring the preferred blocksize if the data is not also aligned to this blocksize?
I'm not sure I parsed this. Can you give an example?
No - I am asking for examples :-). My question is: in which scenario is it helpful for the NBD server to receive non-aligned requests of its preferred blocksize? Isn't that just as bad as receiving requests with a non-preferred blocksize? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«