As was pointed out, rcp.statd is supposed to have a large VSZ, but
mount_nfs should not and my swap was getting used up.
mount_nfs will do an RPC clntudp_create for every attempt, but
only a clnt_destroy after a success.
Here is a rather suspicious fix, I have not looked at rpc call
use in detail:
--- mount_nfs.c.orig Sat Jun 10 11:08:19 2000
+++ mount_nfs.c Sat Jun 10 11:09:06 2000
@@ -784,10 +784,11 @@
warnx("%s", clnt_sperror(clp,
"bad MNT RPC"));
} else {
- auth_destroy(clp->cl_auth);
- clnt_destroy(clp);
retrycnt = 0;
}
+ auth_destroy(clp->cl_auth);
+ clnt_destroy(clp);
+ so = RPC_ANYSOCK;
}
}
if (--retrycnt > 0) {
On 08-Jun-00 Jonathan Hanna wrote:
>
> I am running a fairly recent current and noticed my swap seemed
> a little overused.
>
> bash-2.02$ uname -a
> FreeBSD roller.pangolin-systems.com 5.0-CURRENT FreeBSD 5.0-CURRENT #41: Sun May 14
>11:50:20 PDT 2000 [EMAIL PROTECTED]
sy
> stems.com:/home/src/sys/compile/ROLLER i386
> bash-2.02$ uptime
> 11:27PM up 3 days, 5:15, 7 users, load averages: 0.21, 0.17, 0.14
>
> ps shows:
...
> 0 212 1 29 2 0 263036 0 select IWs ?? 0:00.00 rpc.stat
This is expected.
> This looks big.
> 0 1382 1 0 2 0 3716 352 select I ?? 0:01.02 xterm -geometry
>80x25 -fg springgree
...
> 1000 1504 1 0 10 0 86368 408 nanslp Is ?? 0:07.93 nfs -o bg -o
>noauto ghost-p1:/home/j
>
> This seems rather large as well.
Not expected.
...
> I do remember an nfs mount failing and perhaps being backgrounded.
This was it, in normal circumstances the problem would not show up.
I guess I shouldn't be leaving failing mounts around!
Jonathan Hanna <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
