From: Steve Dickson <SteveD@redhat.com>
To: MINOURA Makoto <minoura@valinux.co.jp>
Cc: nfs@lists.sourceforge.net, taka@valinux.co.jp, yamamoto@valinux.co.jp
Subject: Re: NFSD Flow Control Using the TCP Transport
Date: Mon, 24 Mar 2003 10:07:09 -0500 [thread overview]
Message-ID: <3E7F1F1D.8090206@RedHat.com> (raw)
In-Reply-To: 20030324025133.924651DA3E6@brer.local.valinux.co.jp
Yes I understand its a RPC issue not an NFS issue.
I guess I should have made it clear that I think
that the _RPC_ layer should be able to handle
EAGAINs (using the TCP transport).
The patch you provided does indeed stop the RPC
layer from returning EAGAINs but also stops the flow
of traffic because the sockets with are no longer
being enqueued which in turn means there are no
threads sleeping/waiting (in tcp_sendmsg) when
the svc_write_space routine is called. So once
this flow condition hits, the replys stop which
means the incoming requests also stop and all
the nfsds end up sitting in svc_recv() waiting
for something to do....
0bviously, there is another issue in player here
(which I'm currently debugging), since I do think your
patch make sense....
SteveD.
MINOURA Makoto wrote:
>|> 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.
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-03-24 14:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-19 15:05 NFSD Flow Control Using the TCP Transport Steve Dickson
2003-03-20 4:24 ` MINOURA Makoto
2003-03-20 4:43 ` MINOURA Makoto
2003-03-21 20:38 ` Steve Dickson
2003-03-24 2:51 ` MINOURA Makoto
2003-03-24 15:07 ` Steve Dickson [this message]
2003-03-25 5:32 ` MINOURA Makoto
2003-03-25 11:33 ` Steve Dickson
2003-03-26 5:07 ` MINOURA Makoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E7F1F1D.8090206@RedHat.com \
--to=steved@redhat.com \
--cc=minoura@valinux.co.jp \
--cc=nfs@lists.sourceforge.net \
--cc=taka@valinux.co.jp \
--cc=yamamoto@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.