Re: [Libguestfs] Kernel driver I/O block size hinting
On Jun 15 2022, "Richard W.M. Jones" <rjones(a)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.«