From owner-freebsd-current Mon Jun 1 16:18:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05292 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:18:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05271 for ; Mon, 1 Jun 1998 16:18:47 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA06543; Mon, 1 Jun 1998 16:18:38 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd006490; Mon Jun 1 16:18:32 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA29727; Mon, 1 Jun 1998 16:18:27 -0700 (MST) From: Terry Lambert Message-Id: <199806012318.QAA29727@usr05.primenet.com> Subject: Re: NFS discovery To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Mon, 1 Jun 1998 23:18:27 +0000 (GMT) Cc: mi@video-collage.com, current@FreeBSD.ORG, toasty@home.dragondata.com In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from "Karl Pielorz" at Jun 1, 98 09:30:17 pm X-Mailer: ELM [version 2.4 PL25] 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 > > 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... The program is supposed to hang only until the server comes back up. The problem is the use of TCP, and that the RPC call is not retried after a request ack before a request completion. This is exactly analogous to the FIN_WAIT_2 problem: --> request <-- response 1 <-- response 2 (this one never comes) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message