Re: [Nbd] another?

[Alex Bligh <alex@...872...>]

Folkert,

--On 16 September 2011 10:07:28 +0200 Folkert van Heusden 
<folkert@...421...> wrote:

> queue depth: to adapt the number of outstanding requests to what the
> other end is capable of.

In general you don't need to do this. Firstly, faced with a stream
of requests, the server can simply stop reading from the socket if it's
out of queue depth. There's not really any sensible way to adapt upper
layer behaviour to that.

Secondly, in practice, even with a server with almost infinite queue
depth (and I have generated queue depths of over 100,000 requests on
my test server), you rarely see the queue filling in normal FS operations
beyond a handful of requests, even with flush/fua turned off. This is
because the reordering semantics essentially permit any reordering,
and the block layer/fs would have to retain far too much state for
this to be useful. The possible exception is a huge dd from /dev/zero
(or similar) with a huge block size to an existing file on (say) ext2
which would be broken up into a large number of contiguous maximum
sized write requests. But I don't see much need for the block layer
to adapt it's "send them all as fast as I can" behaviour in this case.

--
Alex Bligh