Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Dec 1998 06:54:10 +0100 (CET)
From:      List User <listuser@netspace.net.au>
To:        freebsd-hackers@FreeBSD.org
Message-ID:  <199812140554.GAA07040@doorway.home.lan>

next in thread | raw e-mail | index | archive | help
Newsgroups: freebsd.hackers
Path: root
From: Kevin Day <toasty@home.dragondata.com>
Subject: NFS thoughts
Content-Type: text/plain; charset=US-ASCII
Received: (from toasty@localhost)
	by home.dragondata.com (8.8.8/8.8.5) id RAA02261
	for hackers@freebsd.org; Sun, 13 Dec 1998 17:42:45 -0600 (CST)
To: hackers
Sender: owner-freebsd-hackers@FreeBSD.ORG
Content-Transfer-Encoding: 7bit
Organization: Private News Host
Precedence: bulk
Message-ID: <199812132342.RAA02261@home.dragondata.com>
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
Delivered-To: vmailer-hackers@freebsd.org
X-Uidl: c2af812d31410c6fccab93303b3ec824
X-Loop: FreeBSD.ORG
Mime-Version: 1.0
Date: Sun, 13 Dec 1998 23:42:45 GMT


I've noticed a few things about NFS. I don't know enough about this to be
useful, so this is a lot of guesswork.

I get my nfs client complaining about the server not responding a lot. I
don't see how this is possible, because the server is connected over 100MB
ethernet, on a very not busy segment, and the server isn't too busy.

This began to make me wonder.... The dynamic retransmit algorithm doesn't
look like it was meant for very high speed links like this.

If the last few calls went very very quickly(which they appear to be), just
a few collisions alone could knock this above the retransmit limit.

I also seem to see this happening a lot right at 3am, when a big cron job
goes off on the server, making the replies come in later. Mounting with -d
seems to help this, but I'm going to experiment with changing the algorithm
to back off in much bigger steps.

Rpc Info:
 TimedOut   Invalid X Replies   Retries  Requests
        4         0      4749     10270   5587819

Usually, after each TimedOut that's occured, 5-10 processes seem to randomly
exit on SIGSEGV. This is another issue that seems seperate, but if I can
prevent timeouts from occuring anyway, this would go away too.

Has anyone ventured down this path already?


Kevin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812140554.GAA07040>