From owner-freebsd-hackers Wed Dec 16 22:24:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11200 for freebsd-hackers-outgoing; Wed, 16 Dec 1998 22:24:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11195 for ; Wed, 16 Dec 1998 22:24:18 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id BAA00607; Thu, 17 Dec 1998 01:27:30 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 17 Dec 1998 01:27:30 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: David G Andersen cc: Karl Denninger , hackers@FreeBSD.ORG Subject: Re: yup, found it (NFS) In-Reply-To: <199812170523.WAA02697@lal.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Dec 1998, David G Andersen wrote: > Lo and behold, Karl Denninger once said: > > What I want to know is whether a "ro,soft" mount has the same > > vulnerability. We use them around here for things like mounting > > the Usenet spool. > > Nope. Soft doesn't seem to affect it (at least, the last time I tested > it). Another cheap fix is to not run any nfsiods, preventing the > asynchronous flush from occuring in the first place. > > We've been hounding on this PR for a while (that's kern/8732. :), and > would love to see a resolution for it. If someone wants to suggest the > proper behavior, I'm more than happy to start drudging up a fix. > p. 322 of Design and Implementation: ...begin... 3. Most system administrators take a middle ground by using an interruptible mount that will wait forever like a hard mount, but checks to see whether a termination signal is pending for the process that is waiting for a server responce. If a signal (such as an interrupt) is sent to a process waiting for an NFS server, the corresponding I/O system call returns with a transient error. (*1) Normally, the process is terminated by the signal.(*2) If the process shooses to catch the signal, then it can decided how to handle the transient failure. This mount option allows interactive programs to be aborted when a server fails, while allowing long-running processes to await the server's return. ...end... This isn't exactly good, a normal write should proceed as normal correct? Maybe it can delay the signal and try an extra 4-5 times and delay the signal untill after the syscall? Has anyone been able to reproduce the same sort of situation with a Solaris box? Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current > -Dave > > -- > work: danderse@cs.utah.edu me: angio@pobox.com > University of Utah http://www.angio.net/ > Department of Computer Science > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message