From: DENIEL Philippe <philippe.deniel@cea.fr>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Thomas Haynes <thomas@netapp.com>, linux-nfs@vger.kernel.org
Subject: Re: Side effects of having NFSv4 mounted over udp
Date: Tue, 14 Dec 2010 08:35:14 +0100 [thread overview]
Message-ID: <4D071E32.905@cea.fr> (raw)
In-Reply-To: <20101213191634.GB2230@fieldses.org>
Hi
> The Linux server allows it, but I've been considering that a
> (low-priority) bug, so it wouldn't be safe to assume it will continue
> working.
>
I am mostly thinking at the client side using as well udp and tcp. Would
the "NFSv4 client over UDP" behaves differently then the same client
over TCP ?
> That aside, if you have a perfect network,
I can trust my network. It's not a WAN, it's located into a very massive
cluster (it's kind of "internal LAN"). It's a very high throughput
network (IB based) so I believe there are less "hardware based reason"
to loose packets.
> NFSv4.0 at least will
> probably work.
OK.
> (Not 4.1 since backchannel setup will fail?)
>
What is erroneous in using UDP for NFSv4.1 backchannels ?
> Are you really sure that you can't make tcp scale to thousands of
> clients?
>
I am a bit afraid of a "No more file descriptors" effect. If I have one
TCP socket per client and thousands of clients, I have less remaining
fds for other purposes. Another point : UDP is a "cheap" protocol. I can
have bunches of clients without overloading the server (a new client
will almost cost nothing to the server, just the cost of a new clientid
negotiation) . I was wondering if it could be reliable to use it for
NFSv4 inside a large cluster.
Philippe
next prev parent reply other threads:[~2010-12-14 7:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 7:46 Side effects of having NFSv4 mounted over udp DENIEL Philippe
2010-12-13 19:04 ` Thomas Haynes
2010-12-13 19:16 ` J. Bruce Fields
2010-12-13 19:47 ` Trond Myklebust
2010-12-14 7:35 ` DENIEL Philippe [this message]
2010-12-14 19:15 ` J. Bruce Fields
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=4D071E32.905@cea.fr \
--to=philippe.deniel@cea.fr \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=thomas@netapp.com \
/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.