Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 May 1999 21:41:46 +0400 (MSD)
From:      "Sergey Ayukov (mailing lists)" <asv1@crydee.sai.msu.ru>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        stable@FreeBSD.ORG
Subject:   Re: NFS question..
Message-ID:  <Pine.BSF.4.05.9905102128080.5643-100000@crydee.sai.msu.ru>
In-Reply-To: <Pine.BSF.4.05.9905101902370.447-100000@herring.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 May 1999, Doug Rabson wrote:

> > > >   Well, I understand the issues (or at least I think so). But I am
> > > >   interested in fast, working NFS implementation (which I know could exist
> > > >   because Linux does it) and not in explanations (system administration is
> > > >   not my primary job). I can trade some bit of stability for performance in
> > > >   case of safe/unsafe NFS write modes.
> > > 
> > > Linux is fast because it violates the spec (this really pisses me off).
> > 
> > Specification violation only affects server, right? Therefore I don't see
> > anything terribly wrong with loose play with specs on server to get
> > reasonable performance. Especially with such a poor design as NFSv2.
> 
> It all depends on the value which you place on the data which the clients
> are writing.

Yes, sure. In ideal case, I would love to mount some directories with less
reliable settings and some with more reliable... This reminds me about
ages long discussion on whether writes should be cached at all (it was
thriving when DOS Smartdrive finally got an option to enable write
caching). My opinion is that they should be cached. After all, it is
impossible to get good performance out of NFSv2 when not doing write
caching. Whether you will rely on UPS or just pray for data to be safe is
another question.

> > > The specification for NFSv2 states that the reply to a write rpc shouldn't
> > > be sent until the write has been completed. From rfc1094:
> >  
> > [skipped]
> >  
> > > The linux server appears to ack the write as soon as it has been handed
> > > off to the kernel's buffer cache (which is certainly not stable storage).
> > > If you want FreeBSD to do this, you can set the sysctl variable
> > > vfs.nfs.async to nonzero. The default for this is off since turning it on
> > > risks data loss.
> > 
> > I have tried it now. Performance numbers are below. Client is OS/2 NFS,
> > with rsize and wsize of 8192.
> > 
> > NFSD Host OS   Network  Throughput, KB/s      Comments
> >                 speed   Read     Write  
> > FreeBSD 3.1      100    4500     610 !        vfs.nfs.async=1
> > FreeBSD 3.1      100             550          vfs.nfs.async=0
> > FTP->FreeBSD     100    6000    3000 
> > FreeBSD 3.1       10    1040     560          vfs.nfs.async=1
> > FreeBSD 3.1       10             330          vfs.nfs.async=0
> > Linux             10    1020     800 !
> > Solaris 7 (i386)  10     900     480
> > 
> > 100Mbit segment is clean (it's just a crossover cable, actually) while
> > 10Mbit segment is more or less loaded. As you see, there's no significant
> > performance improvement with vfs.nfs.async=1 (BTW, where can I find the
> > information about all sysctl variables?) The figure 4500KB/s on read
> > apparently involves disk cache because hard drive itself can't sustain it.
> > FTP read is only 6MB/s due to OS/2 TCP/IP stack limitations and measuring
> > problems (the file I was testing on is just 12MB). FTP write is limited by
> > both local read and remote write.
> 
> Could I have a copy of your test program? The 100Mbit performance ought to
> be better than this.

Test program is File Commander for OS/2, available from many places, e.g. 
ftp://hobbes.nmsu.edu/pub/incoming/fc2_210.zip

> > > Alternatively you can use NFSv3 which uses a more complex protocol which
> > > allows the server to delay the writes safely. If the linux clients can't
> > > do NFSv3, perhaps you would consider replacing them with FreeBSD
> > > clients...
> > 
> > I have DOS and OS/2 clients, and I can't change that, unfortunately. While
> > performance for DOS clients is more or less acceptable (they are not very
> > fast machines anyway), I am concerned about OS/2 client performance.
> > Windoze clients connect to Samba which unfortunately is also very slow on
> > writes for unknown reasons, but that's another thread...
> 
> I would have thought the OS/2 client could use SMB.  I thought the
> performance of samba was pretty good on FreeBSD. Perhaps it could be tuned
> a bit (samba has a boatload of tuning parameters).

I don't know why I am having such a bad luck with FreeBSD, but I am only
getting about 300KB/s on writes over 10MBit network while exchange between
Windoze machines yields about 900KB/s. Someday I will try SMB client on
OS/2, but I was pretty happy with NFS -- until I switched to FreeBSD.

---------------------------------------------------------------------------
Dr. Sergey Ayukov                          Sternberg Astronomical Institute
http://www.ayukov.com                                        Moscow, Russia
http://crydee.sai.msu.ru/index-asv.html



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" 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.4.05.9905102128080.5643-100000>