All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Fabian Steiner <lists-A1xC5SIKT5unwkN7LPkuEg@public.gmane.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [NFS] Attempting to mount a large number of directories
Date: Tue, 08 Jan 2008 12:07:43 +0900	[thread overview]
Message-ID: <1199761663.3155.17.camel@raven.themaw.net> (raw)
In-Reply-To: <200801072228.58507.lists-A1xC5SIKT5unwkN7LPkuEg@public.gmane.org>


On Mon, 2008-01-07 at 22:28 +0100, Fabian Steiner wrote:
> Ian Kent wrote:
> >> [...]
> > I see no-one else wanted to buy into this.
> > I'm not really surprised.
> 
> Thanks a lot for your explainations! Now it is much easier to understand how 
> things work on the low-level area.
> 
> > Judging by your attempt to use the insecure option I assume you actually
> > know that you're running out of port space on the client. The server, of
> > course, consumes only a few ports, like ports for mountd, portmap (or
> > rpcbind) and NFS and because it's a server and it reuses the same port
> > since the different port used on the client makes the tupple
> > clientaddr,clientport,serveraddr,serverport unique. Point is that port
> > space is consumed on the client not the server.
> >
> > So running out of port space is a client problem and the reason it
> > happens is that autofs and mount probe to see if the server is up and
> > what version of NFS is available etc. before doing the mount. This can
> > result in as many a 9 ports consumed for each mount and the ports that
> > aren't continuing to be used can't be reused before a timeout has
> > passed. I think it's about 60 seconds, and is required for the TCP
> > implementation to function properly. So you run out of available ports
> > fairly quickly if you issue many mount requests at once.
> >
> > Quite a bit of work has been done to reduce the port usage over time and
> > I think it has been included in recent nfs-utils releases so perhaps a
> > later nfs-utils will help.
> 
> On the affected machines nfs-utils-1.0.7 has been installed so far. Picking up 
> your hint we forced an upgrade from Ubuntu Dapper to Ubuntu Gutsy with 
> version 1.1.1~git-20070709 being installed and obviously this solved the 
> majority number of problems. Now approx. 400 directories can be mounted. Of 
> course, the entire issue requires further investigation; we are quite content 
> about the current situation, though.

Great, you may also find that specifying the protocol as a mount option,
proto=tcp for example, will reduce the overhead further.

Ian



      parent reply	other threads:[~2008-01-08  3:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-24 11:00 [NFS] Attempting to mount a large number of directories Fabian Steiner
     [not found] ` <200712241200.08410.lists-A1xC5SIKT5unwkN7LPkuEg@public.gmane.org>
2008-01-07  6:07   ` Fabian Steiner
2008-01-07  8:45   ` Ian Kent
     [not found]     ` <1199695504.3156.69.camel-J+SFD3YVfrQ/gntp4R1GGQ@public.gmane.org>
2008-01-07 21:28       ` Fabian Steiner
     [not found]         ` <200801072228.58507.lists-A1xC5SIKT5unwkN7LPkuEg@public.gmane.org>
2008-01-08  3:07           ` Ian Kent [this message]

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=1199761663.3155.17.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lists-A1xC5SIKT5unwkN7LPkuEg@public.gmane.org \
    /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.