From: minoura@valinux.co.jp (MINOURA Makoto)
Subject: Re: NFSD Flow Control Using the TCP Transport
Date: Mon, 24 Mar 2003 11:51:33 +0900
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <20030324025133.924651DA3E6@brer.local.valinux.co.jp>
References: <3E78872B.5020702@RedHat.com>
 <20030320042454.496801DA3E6@brer.local.valinux.co.jp>
 <3E7B7853.4020605@RedHat.com>
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Cc: nfs@lists.sourceforge.net, taka@valinux.co.jp,
	yamamoto@valinux.co.jp
Return-path: <nfs-admin@lists.sourceforge.net>
Received: from vagw.valinux.co.jp ([210.128.90.14] helo=brer.local.valinux.co.jp)
	by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 18xI3k-0007Ie-00
	for <nfs@lists.sourceforge.net>; Sun, 23 Mar 2003 18:51:36 -0800
To: Steve Dickson <SteveD@redhat.com>
In-Reply-To: <3E7B7853.4020605@RedHat.com>
 (Steve Dickson's message of "Fri, 21 Mar 2003 15:38:43 -0500")
Errors-To: nfs-admin@lists.sourceforge.net
List-Help: <mailto:nfs-request@lists.sourceforge.net?subject=help>
List-Post: <mailto:nfs@lists.sourceforge.net>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/nfs>,
	<mailto:nfs-request@lists.sourceforge.net?subject=subscribe>
List-Id: Discussion of NFS under Linux development,
	interoperability,
	and testing. <nfs.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/nfs>,
	<mailto:nfs-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=nfs>


|> In <3E7B7853.4020605@RedHat.com>
|>  Steve Dickson <SteveD@redhat.com> wrote:

> So If I understand what your saying, EAGAINs or partial writes are 
> interpreted
> as fatal errors. This confuse me. EAGAINs or partial writes are flow 
> control
> issues not fatal errors. Just like on the client side, shouldn't the
> thread sleep until there is room? Closing down the socket seems a
> bit drastic... Or am I missing something?

In general you are right, but as of Linux kNFSd something
like a flow control is done in the RPC layer.

In kNFSd multiple nfsd threads share a single socket and to
avoid data mixture a sendto call must be atomic.  In order
to guarantee this the threads sleep in the RPC layer until
there is enough TCP write space.  By doing so EAGAIN can be
interpreted as something wrong is going on.

But since the free space calculation was wrong this
assumption was broken.  The patch attached in my previous
mail corrects this.

-- 
Minoura Makoto <minoura@valinux.co.jp>
Engineering Dept., VA Linux Systems Japan


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs