From owner-freebsd-current Sun Mar 8 03:20:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA14445 for freebsd-current-outgoing; Sun, 8 Mar 1998 03:20:07 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA14399 for ; Sun, 8 Mar 1998 03:20:01 -0800 (PST) (envelope-from pantzer@sister.ludd.luth.se) Received: from sister.ludd.luth.se (pantzer@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id MAA13128; Sun, 8 Mar 1998 12:19:57 +0100 Message-Id: <199803081119.MAA13128@zed.ludd.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: Mikael Karpberg cc: current@FreeBSD.ORG Subject: Re: Okay, -current should be conditionally safe to use In-reply-to: Your message of "Sun, 08 Mar 1998 01:28:51 +0100." <199803080028.BAA03950@ocean.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Mar 1998 12:19:56 +0100 From: Mattias Pantzare Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > another interesting thing to try is: > > > > sysctl -w vfs.nfs.async=1 > > > > on the server. This is better (safer) than softupdates, but you *can* > > have data lossage, due to writes not being committed to disk. It is > > a good idea to have a UPS when using the above option. > > We certainly don't have a UPS. > What exactly does turning on that sysctl mean? That we can get an > inconsistant state on the disk, like with mount option async, or that > writes are ACKed (or whatever you call it) directly, and then queued for > a normal write to the disk according to the disks mount options? > The latter would mean nothing except data loss at a crash, I guess, and > that doesn't seem so bad, since data written the second a crash or > power outage happens is still pretty much doomed. If vfs.nfs.async is on and the NFS server crashes and has data not written to the disk, then the client won't know that the data never got to the disk and will continue as nothing hapend. Not very good... If nfs.async was not on then the client would have repeated the write when the server was up again. UPS and a stable OS and vfs.nfs.async => presto. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message