Re: [Nbd] performance
- To: Wouter Verhelst <w@...112...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] performance
- From: Goswin von Brederlow <goswin-v-b@...186...>
- Date: Tue, 10 May 2011 00:06:55 +0200
- Message-id: <87bozb8r5s.fsf@...860...>
- In-reply-to: <20110509095111.GB9905@...510...> (Wouter Verhelst's message of "Mon, 9 May 2011 11:51:11 +0200")
- References: <BANLkTi=T5o9HyLC9vAxx24S3tniskCojtg@...18...> <20110509095111.GB9905@...510...>
Wouter Verhelst <w@...112...> writes:
> On Fri, May 06, 2011 at 11:10:29AM +0200, Folkert van Heusden wrote:
>> Hi,
>>
>> I have a suggestion for performance enhancement of NBD.
>> The idea is that between each request the client and server exchange a
>> message. Since networks are slow, this takes a while.
>
> The current implementation works that way, because nbd-server is not
> doing asynchronous reads, and therefore can only handle one request at a
> time. But the protocol doesn't require it, and changing the
> implementation so that it can handle one request while preparing to
> handle another is what I meant with the performance improvements that I
> mailed about earlier.
Does the kernel already pipeline requests?
>> Maybe we can, at least for write requests, send a couple of write
>> commands with their data without immediately waiting for the reply and
>> then if, say, 32 of them are send, wait for the acknowledgments. If I
>> remember correctly that's also how iSCSI does it.
>
> There's no reason to limit them to write requests only. However read and
> write requests do need to remain somewhat ordered, otherwise there are
> going to be some issues.
Two cases: read after write and write after read.
While I see that some bad implementation could read a block that is
still writing I wonder if that could ever happen with linux? Wouldn't
the data remain in cache as long as the NBD server hasn't acked the
write?
I guess one always has to protect read requests from later comming write
requests.
MfG
Goswin
Reply to: