Folkert, --On 16 September 2011 10:07:28 +0200 Folkert van Heusden <[email protected]> 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 ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
