From owner-freebsd-current Fri Oct 11 17:15:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA08555 for current-outgoing; Fri, 11 Oct 1996 17:15:59 -0700 (PDT) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA08550 for ; Fri, 11 Oct 1996 17:15:57 -0700 (PDT) Received: from pauling.salk.edu (pauling [198.202.70.108]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id RAA23290; Fri, 11 Oct 1996 17:15:28 -0700 (PDT) Date: Fri, 11 Oct 1996 17:15:31 -0700 (PDT) From: Tom Bartol To: Hidetoshi Shimokawa cc: dfr@render.com, current@FreeBSD.ORG Subject: Re: NFS weirdness in -current In-Reply-To: <9764.844967087@sat.t.u-tokyo.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 11 Oct 1996, Hidetoshi Shimokawa wrote: > bartol> Yes, it does sound like that problem now that you point it out. > bartol> > bartol> Hidetoshi, is there anything I can do to help out? > > I already made a patch and send it to freebsd-lite2 list. > (I guess you can find it by mailing list archive search, > keyword is "Delayed write patch".) > > Doug will commit it to -current tomorrow(it may depends on time zone :-). > If you cannot wait it, I will send you the patch. > > Please try the patch. > > /\ Hidetoshi Shimokawa > \/ simokawa@sat.t.u-tokyo.ac.jp > PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp > Hi, Sorry for the delay in getting back you on trying this patch. I see that the patch has already been committed, great! Here are my results: 1) the patch fixes the anomalous behavior -- nfs operations no longer block other nfs operations when they shouldn't. 2) with vfs.nfs.dwrite=1, nfs reads go at 400KBps and nfs writes go at 600KBps! Not too shabby! During a write of a file called "ick", do an "ls -al ick" in another xterm shows the file's size increasing in large chunky, and infrequent increments. 3) with vfs.nfs.dwrite=0, nfs reads go at 250KBps and nfs writes go at 250KBps. "ls -al ick" shows the file's size increasing smoothly over time. 4) with 2.2-960801-SNAP we got 600KBps reads and 300KBps writes so a few things have changed in -current. "ls -al ick" shows file's size increasing somewhat smoothly, sort of half-way between behavior described in 2 and 3 above. In the tests above we NFS mounted a filesystem served by an Auspex NS200 running Auspex kernel 1.8M1Z1 (a SunOS 4.1.4 variant). We were reading or writing a 10MB file over a dedicated switched 10BT ethernet connection to the Auspex. Hope this helps, Tom