From: minoura@valinux.co.jp (MINOURA Makoto)
Subject: Re: NFSD Flow Control Using the TCP Transport
Date: Thu, 20 Mar 2003 13:43:51 +0900
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <20030320044351.5974B1DA3E6@brer.local.valinux.co.jp>
References: <3E78872B.5020702@RedHat.com>
 <20030320042454.496801DA3E6@brer.local.valinux.co.jp>
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Cc: nfs@lists.sourceforge.net
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 18vruD-00051r-00
	for <nfs@lists.sourceforge.net>; Wed, 19 Mar 2003 20:43:53 -0800
To: Steve Dickson <SteveD@RedHat.com>
Cc: taka@valinux.co.jp, yamamoto@valinux.co.jp
In-Reply-To: <20030320042454.496801DA3E6@brer.local.valinux.co.jp>
 (MINOURA Makoto's message of "Thu, 20 Mar 2003 13:24:54 +0900")
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 <20030320042454.496801DA3E6@brer.local.valinux.co.jp>
|>  minoura@valinux.co.jp (MINOURA Makoto) wrote:

> Current implementation closes the socket on EAGAIN/partial
> write, but has some delay.  During this delay on-queue
> messages are unintentionally sent (in case the NFS traffic
> is busy).  We addressed this problem by removing the delay
> (close the socket immediatly) but sending the remaining
> correctly should be better.

Forgot to note: I suppose the cause of the test failure is
that someone (other NFSd thread) sent something from the
same socket before the socket is actually closed.  This
breaks the `recordmark'-separated message stream and the
peer (client) would be confused.

To address this,

> We think socket lock mechanism (sk_sem) should be also
> backported to serialize the output.

should also be enough.

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


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs