Date: Mon, 10 May 1999 19:06:30 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Sergey Ayukov (mailing lists)" <asv1@crydee.sai.msu.ru> Cc: Mats Lofkvist <mal@algonet.se>, stable@FreeBSD.ORG Subject: Re: NFS question.. Message-ID: <Pine.BSF.4.05.9905101902370.447-100000@herring.nlsystems.com> In-Reply-To: <Pine.BSF.4.05.9905102008190.5298-100000@crydee.sai.msu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 May 1999, Sergey Ayukov (mailing lists) wrote: > 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. > > > 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. > > > 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). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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.9905101902370.447-100000>