Even slower NFS mounting with 2.4.0

Even slower NFS mounting with 2.4.0

[Christian Ullrich]

Hello!

About three weeks ago, I complained loudly about very slow NFS mounts
involving a 2.2.17 server and a 2.2.18 client.

Today, I complain loudly about *extremely* slow NFS mounts
with the very same server and the same client now running 2.4.0.

Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0,
every mount takes exactly five minutes, which is way too long.

According to syslog, the server begins and completes its operations
related to the mount in under one second, so it seems to me that
mount on the client just takes a nap in D state.
Although the messages in the client's syslog look critical to me,
once the fs is mounted, it works fine.

Syslog on client:

Jan  6 00:18:06 c kernel: portmap: server localhost not responding, timed out
Jan  6 00:19:46 c kernel: portmap: server localhost not responding, timed out
Jan  6 00:19:46 c kernel: lockd_up: makesock failed, error=-5
Jan  6 00:21:26 c kernel: portmap: server localhost not responding, timed out

I called the mount command five minutes before the final message above.

I tried NFS with and without NFSv3 code, with no change at all.

Please help me.

-- 
Christian Ullrich		     Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Mohammad A. Haque]

Hrm. I'm not seeing this problem on my setups. 

Did you send details about your configurationlast time .. Could you
resend?

Christian Ullrich wrote:
> 
> Hello!
> 
> About three weeks ago, I complained loudly about very slow NFS mounts
> involving a 2.2.17 server and a 2.2.18 client.
> 
> Today, I complain loudly about *extremely* slow NFS mounts
> with the very same server and the same client now running 2.4.0.
> 
> Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0,
> every mount takes exactly five minutes, which is way too long.
> 
> According to syslog, the server begins and completes its operations
> related to the mount in under one second, so it seems to me that
> mount on the client just takes a nap in D state.
> Although the messages in the client's syslog look critical to me,
> once the fs is mounted, it works fine.
> 
> Syslog on client:
> 
> Jan  6 00:18:06 c kernel: portmap: server localhost not responding, timed out
> Jan  6 00:19:46 c kernel: portmap: server localhost not responding, timed out
> Jan  6 00:19:46 c kernel: lockd_up: makesock failed, error=-5
> Jan  6 00:21:26 c kernel: portmap: server localhost not responding, timed out
> 
> I called the mount command five minutes before the final message above.
> 
> I tried NFS with and without NFSv3 code, with no change at all.
> 
> Please help me.

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/ 
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Christian Ullrich]

* Christian Ullrich wrote on Saturday, 2000-01-06:

> Using 2.2.18, every [NFS] mount took about 15 seconds, now, using 2.4.0,
> every mount takes exactly five minutes, which is way too long.

Ok, it's fixed now. Thanks to all of you, and especially the
(right now) three people who gave me the helpful hint 
to start the portmapper on the client as well.

l-k is great!

-- 
Christian Ullrich		     Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Russell King]

Christian Ullrich writes:
> About three weeks ago, I complained loudly about very slow NFS mounts
> involving a 2.2.17 server and a 2.2.18 client.
> 
> Today, I complain loudly about *extremely* slow NFS mounts
> with the very same server and the same client now running 2.4.0.

In all cases, you need to either:

1. Provide the option "nolock" to turn of NFS file locking (which means
   that things like elm can't lock mailboxes and will get upset if the
   mailboxes are on a NFS partition).

2. before running the mount command:
   a) make sure the loopback interface is up and running
   b) ensure that the portmapper (called portmap or rpc.portmap) is
      running.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Alan Cox]

> I called the mount command five minutes before the final message above.
> I tried NFS with and without NFSv3 code, with no change at all.

This is caused by 2.3/2.4 changes in the network code error reporting of
unreachables with UDP I suspect. It looks like the NFS code hasn't yet caught
up with the error notification stuff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Trond Myklebust]

>>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    >> > This is caused by 2.3/2.4 changes in the network code error
    >> > reporting of unreachables with UDP I suspect. It looks like
    >> > the NFS code hasn't yet caught up with the error notification
    >> > stuff
    >>
    >> No. It was the fact that he was forgetting to start the
    >> portmapper before mounting an NFS partition with locking
    >> enabled.

     > Its both. If you support the error notification then you see
     > the PORT UNREACH and you abandon early even if the user makes
     > that error

Hmm... How should we respond to that sort of thing? In principle the
NFS layer supposes that if we have a hard mount, then unreachable
ports etc are a temporary problem, and we should wait them out.  (In
fact, I've made an RPC 'ping' routine that improves on that behaviour
but which unfortunately didn't make it into 2.4.0.)

If we want to check that the port is reachable at the moment when we
mount, I think we should concentrate on making 'mount' more
intelligent. Perhaps have it RPC-ping the various ports (including the
local portmapper when we specify locking)?

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Even slower NFS mounting with 2.4.0

[Alan Cox]

> Hmm... How should we respond to that sort of thing? In principle the
> NFS layer supposes that if we have a hard mount, then unreachable
> ports etc are a temporary problem, and we should wait them out.  (In
> fact, I've made an RPC 'ping' routine that improves on that behaviour
> but which unfortunately didn't make it into 2.4.0.)

That makes reasonable sense once mounted. I think mount needs to be polite
until it decides the mount is made


> If we want to check that the port is reachable at the moment when we
> mount, I think we should concentrate on making 'mount' more
> intelligent. Perhaps have it RPC-ping the various ports (including the
> local portmapper when we specify locking)?

That would work.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/