Re: [Libguestfs] Kernel driver I/O block size hinting
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.«
Reply to: