From owner-freebsd-current Wed Apr 21 8:19: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 0001915357; Wed, 21 Apr 1999 08:18:54 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id KAA03575; Wed, 21 Apr 1999 10:32:20 -0500 (EST) Date: Wed, 21 Apr 1999 10:32:19 -0500 (EST) From: Alfred Perlstein To: Matthew Dillon Cc: Bob Bishop , Wilko Bulte , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files) In-Reply-To: <199904202334.QAA00567@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Apr 1999, Matthew Dillon wrote: > NFS patch #6 is now available for -current. This patch has been > extensively tested with NFS and with FFS+softupdates and has not > screwed up yet, so I'm reasonably confident that it will not > scrap whole filesystems :-) > > http://www.backplane.com/FreeBSD4/ > > Please remember to back-out all prior patches before applying this one. > Note that the memory-zeroing code ( which is committed to -current ), is > *correct* and should not be disabled. > > This patch is for CURRENT ONLY. Do not apply to -3.x unless you like > seeing computer equipment melt! > > The only difference between patch #5 and patch #6 is that the VMIO > directory backing mods have been removed. These mods worked, but > appear to have resulted in an occassional softupdates panic during > 'installworld'. It is more important for us to have a rock solid > implementation then majorly optimized implementation, so... The > patch will probably return later on when we figure out why it is > causing softupdates to panic. > > Please post bug reports to -current or -hackers. .(14:57:37)(root@thumper.reserved) /usr # mount /dev/da0s1a on / (local, soft-updates, writes: sync 598 async 27021) /dev/da0s1g on /home (local, soft-updates, writes: sync 25 async 679) /dev/da0s1f on /usr (local, soft-updates, writes: sync 738 async 42763) /dev/da0s1e on /var (local, soft-updates, writes: sync 106 async 1783) procfs on /proc (local) server:/usr/src on /usr/src server:/usr/obj on /usr/obj server:/home/ncvs on /home/ncvs /usr/src # for i in 1 2 3 4 5 6 ; do make world -j64 ; echo "$i done.." ; done >& ../build.log nfs server server:/usr/obj: not responding nfs server server:/usr/obj: is alive again .(15:00:59)(root@thumper.reserved) /usr # uptime 3:01PM up 6:55, 1 user, load averages: 1.72, 7.03, 7.34 .(15:01:47)(root@thumper.reserved) /usr # grep "^[0-9] done" build.log 1 done.. 2 done.. 3 done.. .(15:05:05)(root@thumper.reserved) /usr # .(03:33:51)(root@bright.reserved) /usr/obj # uptime 10:02AM up 14:40, 1 user, load averages: 0.18, 0.16, 0.14 yeah the clocks are not setup properly :) but otherwise i'm just gonna say HOLY SH*T you fixed NFS! :) Actually I just realized I'm not running nfsiod on the client, I just started up 8 of them (it's an SMP box). So far no problems. I'm using the default mount operations, as far as NFS server not responding messages, i have no clue, but the server is still up and i've seen that message happen when a lot of pressure is being put on an NFS server even though everything is fine. Normally i'd have client corruption and a rebooted server with both of them locked up sending out garbled RPC about now, but everything seems fine... great work! 2 questions I had: 1) you said you disabled partial writes that were causing these mmap() problems, they were causing problems because NFS had to muck with the structures directly in order to do zero copy? so if our NFS impelementation didn't do that it wouldn't be an issue probably. I know it's a good thing for speed and definetly essensial, but i'm not sure i understand NFS and the FS getting out of sync. 2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you an Julian talking about VM issues. :) Something you guys brought up was problems with mmap() + read()/write() no staying in sync and requireing an msync() to correctly syncronize. I really didn't understand how this could happen except recently I figured that my first question could be the answer. Does this problem only happen on NFS mounted dirs? Is it fixed? thanks again, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message