Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Apr 1999 10:32:19 -0500 (EST)
From:      Alfred Perlstein <bright@rush.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Bob Bishop <rb@gid.co.uk>, Wilko Bulte <wilko@yedi.iaf.nl>, 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)
Message-ID:  <Pine.BSF.3.96.990421101558.11384i-100000@cygnus.rush.net>
In-Reply-To: <199904202334.QAA00567@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990421101558.11384i-100000>