All of lore.kernel.org
 help / color / mirror / Atom feed
* NFS mount error
@ 2001-08-31 19:50 Stefan Nunninger
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Nunninger @ 2001-08-31 19:50 UTC (permalink / raw)
  To: linuxppc-embedded


Hello,

Sorry this is slightly off topic but probably someone has seen this error
before.

I've been using a embedded device running Linux quite some time no
without problems. Linux mounted it's file system from a NFS server running
on a Red Hat 6.0 machine. Recently I had to change the server. The new NFS
server is running on a SuSE 7.2 distribution. Now my embedded device is not
able anymore to mount it's file system. This is what I get to see:
...
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
VFS: Mounted root (NFS filesystem).
Freeing unused kernel memory: 56k init
unlock_kernel
Warning: unable to open an initial console.
RPC: sendmsg returned error 101
nfs: server 192.168.0.1 not responding, still trying
RPC: sendmsg returned error 101
nfs: server 192.168.0.1 not responding, still trying

The filesystem is stored in the directory /tftpboot on the NFS server.
The /etc/exports file of the NFS server contains this line:
/tftpboot *(rw,no_root_squash,no_all_squash)

The server is running Linux 2.4.4 (original SuSE kernel) with
userspace NFS daemon 2.2beta47.

The log file of the NFS server shows no error message but this:
mountd[734]: /tftpboot has been mounted by 192.168.0.8

I am able to mount the directory with the file system from another PC.

Has anybody an idea what is the reason for the error message and how it can
be resolved? Thanks for any hint.
	Stefan Nunninger

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* NFS mount error
@ 2006-03-08  8:59 Vijay Chauhan
  2006-03-08 16:30 ` Chuck Lever
  0 siblings, 1 reply; 4+ messages in thread
From: Vijay Chauhan @ 2006-03-08  8:59 UTC (permalink / raw)
  To: nfs

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

hi,
im doing mount/unmount in an infinte loop
while [ "a" == "a" ];
do
mount -t nfs -o tcp server:/filepath /mount-point
unmount -at nfs
done

after some successful mount/unmount its giving error message like

RPC: can't bind to reserved port.

what does it means?

TIA,
Vijay

[-- Attachment #2: Type: text/html, Size: 515 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NFS mount error
  2006-03-08  8:59 Vijay Chauhan
@ 2006-03-08 16:30 ` Chuck Lever
  2006-03-10 11:23   ` Vijay Chauhan
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2006-03-08 16:30 UTC (permalink / raw)
  To: Vijay Chauhan; +Cc: nfs

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

Vijay Chauhan wrote:
> hi,
> im doing mount/unmount in an infinte loop
> while [ "a" == "a" ];
> do
> mount -t nfs -o tcp server:/filepath /mount-point
> unmount -at nfs
> done
>  
> after some successful mount/unmount its giving error message like
>  
> RPC: can't bind to reserved port.
>  
> what does it means?
>  
> TIA,
> Vijay

there are a limited number of reserved ports on every host.  each mount 
operation takes up to 5 ports (5 sockets for contacting the server's 
portmapper, mount daemon, and so on).  when each mount is finished, it 
leaves 4 sockets in TIME_WAIT and one, to the NFS server, is ESTABLISHED.

after about 120 seconds the TIME_WAIT sockets will go away, freeing 
those ports.  but if you mount in a tight loop, you are not giving these 
sockets long enough to time out.  so all the reserved ports are used up 
with TIME_WAIT sockets.  you can see this with the "netstat" command.

if you wait a few minutes, you will find that the ports free up and you 
can do more mounts.  or you can add a "sleep" in your loop.

there has been some mitigation in later kernels.

1.  port numbers can be reused immediately in some circumstances.

2.  steve d has reduced the number of sockets used for a mount request.

3.  NFSv4 can usually skip the portmapper query.

4.  the RPC client will attempt to connect to the default port first, 
and use the portmapper only if the requested service isn't available on 
the default port.

but a tight loop like yours will still probably consume all the reserved 
ports available on a client.

[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NFS mount error
  2006-03-08 16:30 ` Chuck Lever
@ 2006-03-10 11:23   ` Vijay Chauhan
  0 siblings, 0 replies; 4+ messages in thread
From: Vijay Chauhan @ 2006-03-10 11:23 UTC (permalink / raw)
  To: cel; +Cc: nfs

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

Thanks for ur explained reply.

- Vijay


On 3/8/06, Chuck Lever <cel@citi.umich.edu> wrote:
>
> Vijay Chauhan wrote:
> > hi,
> > im doing mount/unmount in an infinte loop
> > while [ "a" == "a" ];
> > do
> > mount -t nfs -o tcp server:/filepath /mount-point
> > unmount -at nfs
> > done
> >
> > after some successful mount/unmount its giving error message like
> >
> > RPC: can't bind to reserved port.
> >
> > what does it means?
> >
> > TIA,
> > Vijay
>
> there are a limited number of reserved ports on every host.  each mount
> operation takes up to 5 ports (5 sockets for contacting the server's
> portmapper, mount daemon, and so on).  when each mount is finished, it
> leaves 4 sockets in TIME_WAIT and one, to the NFS server, is ESTABLISHED.
>
> after about 120 seconds the TIME_WAIT sockets will go away, freeing
> those ports.  but if you mount in a tight loop, you are not giving these
> sockets long enough to time out.  so all the reserved ports are used up
> with TIME_WAIT sockets.  you can see this with the "netstat" command.
>
> if you wait a few minutes, you will find that the ports free up and you
> can do more mounts.  or you can add a "sleep" in your loop.
>
> there has been some mitigation in later kernels.
>
> 1.  port numbers can be reused immediately in some circumstances.
>
> 2.  steve d has reduced the number of sockets used for a mount request.
>
> 3.  NFSv4 can usually skip the portmapper query.
>
> 4.  the RPC client will attempt to connect to the default port first,
> and use the portmapper only if the requested service isn't available on
> the default port.
>
> but a tight loop like yours will still probably consume all the reserved
> ports available on a client.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2282 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-03-10 11:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-31 19:50 NFS mount error Stefan Nunninger
  -- strict thread matches above, loose matches on Subject: below --
2006-03-08  8:59 Vijay Chauhan
2006-03-08 16:30 ` Chuck Lever
2006-03-10 11:23   ` Vijay Chauhan

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.