Path: utzoo!utgpu!water!watmath!clyde!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <502@athos.rutgers.edu> Date: 25 Dec 87 07:02:12 GMT References: Organization: Rutgers Univ., New Brunswick, N.J. Lines: 15 I guess I'm about to jump on the bandwagon for turning on NFS checksumming. We just had Sun field service replace an Ethernet board because we started noticing corrupted files transported via NFS. No gateways or bridges involved. It was apparently a failure in the Ethernet interface board. After the vacation I'm going to look into turning on checksumming everywhere. This was not our first problem. The other one was due to a design bug in the ACC 1822 Multibus card. When put into a gateway with more than one Ethernet card, the load got too heavy for the chips they used to drive it. The bus arbitration didn't work. It stomped on the bus cycles of other devices. Result was random garbaging of data. TCP worked fine, but NFS files were garbaged. The board has just recently been fixed. Of course with these low-rate failures, if checksumming were turned on, we would probably never even know we had a problem. On the other hand, it seems a bit drastic to use garbage in user files as a diagnostic.