From owner-freebsd-current  Mon Jun  1 14:36:57 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA12470
          for freebsd-current-outgoing; Mon, 1 Jun 1998 14:36:57 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from www.video-collage.com (www.video-collage.com [206.15.171.132])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12273
          for <current@freebsd.org>; Mon, 1 Jun 1998 14:36:03 -0700 (PDT)
          (envelope-from mi@xxx.video-collage.com)
Received: from xxx.video-collage.com (xxx.video-collage.com [199.232.254.68])
	by www.video-collage.com (8.8.5/8.8.5) with ESMTP id RAA02135
	for <current@freebsd.org>; Mon, 1 Jun 1998 17:34:37 -0400 (EDT)
Received: (from mi@localhost)
	by xxx.video-collage.com (8.8.8/8.8.7) id RAA21867
	for current@freebsd.org; Mon, 1 Jun 1998 17:35:49 -0400 (EDT)
	(envelope-from mi)
From: Mikhail Teterin <mi@video-collage.com>
Message-Id: <199806012135.RAA21867@xxx.video-collage.com>
Subject: Re: NFS discovery
In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from Karl Pielorz at "Jun 1, 98 09:30:17 pm"
To: current@FreeBSD.ORG
Date: Mon, 1 Jun 1998 17:35:49 -0400 (EDT)
X-Face: 
	%UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
		 hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
		 y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL35 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Karl Pielorz once stated:

=> NFS hung ups are a strange topic, in my experience. People agree that
=> they are "bad", but one is not supposed to complain about them...

=I remember having a long conversation with a friend a few years back
=(can I get any more vague?) - Where he was praising NFS's ability to
=crash - as it assures that say your running a program on a remote
=system, it will either run to completion - or hang if the server
=dies... This I presume works on the assumption that it helps somehow
=to have a client that's 'hung' in mid-air (i.e. at least you know if
=failed) rather than risking any corruption that might have been caused
=by the server disappearing for a while...

This is true. However, there must be a thing right before having to
reboot the whole system. I must be able to avoid the total reboot of the
client (in which case my in-mid-air app will loose its data anyway) and
getting rid of the hung mountpoint.

=I think you can change this behaviour - have a look at the man page
=for 'mount_nfs' - in particular things like the '-i' option & 'soft'
=mounting etc...

This is different and, AFAIK, it slows down your usual NFS work...

	-mi

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