Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!Firewall!genesis!kdenning From: kdenning@genesis.Naitc.Com (Karl Denninger) Newsgroups: comp.protocols.nfs Subject: Re: NFS performance Summary: More data points on NFS performance, and a few questions Message-ID: <1991Jun13.164017.29944@Firewall.Nielsen.Com> Date: 13 Jun 91 16:40:17 GMT References: <1388@appli.se> <623@appserv.Eng.Sun.COM> Sender: news@Firewall.Nielsen.Com (Usenet News) Organization: AC Nielsen Co., Bannockburn IL Lines: 54 Nntp-Posting-Host: genesis.naitc.com In article <623@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >niklas@appli.se (Niklas Hallqvist) writes: >> Truely enough, I got only 25k/sec on transfer from a SCO Unix to an ISC 2.0.2. >> The other way around it was 200k/sec, that's an order of magnitude involved here! > >I suspect you are running into the following NFSism: all writes to an NFS >server are turned into sync writes on the server (like you opened with >O_SYNC). This is very slow, large transfers can be 3x or more slower on >writes than reads. > >The reason for this has to do with NFS' stateless nature - it can't ACK >the write until the data is safe; otherwise the server could crash and the >client would lose data. The interesting thing is, there is little or no disk activity going on (from a look at the wait I/O times and queues)..... on a Sun, on the other hand, there IS a lot of disk activity during an NFS write operation. The MIPS systems I've used don't suffer from this problem. I don't quite understand the fanatacism with which people preach the NFS stateless nature, O_SYNC and all that. The fact is that a crash of a LOCAL Unix machine with the normal block buffering scheme can easily cause the loss of data -- in this case, the write(2) call returned "ok" but it really might not be "OK"! This is true whether the problem is later found to be a bad disk sector, the machine panicing, or any one of a number of other causes. Normal disk I/O on Unix machines is NOT reliable enough to say "if you get a good return from write(), the data is safely on disk". If you WANT reliable I/O, you open with O_SYNC and take the performance hit. Why wasn't this option designed into NFS? It could have been set up so that for Non-Unix clients (which expect reliable I/O and don't have a "buffer cache" that can be disabled on a file I/O basis) default to O_SYNC mode... this is easily handled by making the Unix "open()" hook set the "no sync" flag... Or was this a short-cut that has just never been repaired? -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.