Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: inodes on remote disks (was: running out of inodes?) Message-ID: <1679@auspex.auspex.com> Date: 22 May 89 18:27:35 GMT References: <68000001@sts> <17641@mimsy.UUCP> <16064@elroy.Jpl.Nasa.Gov> Reply-To: guy@auspex.auspex.com (Guy Harris) Distribution: comp Organization: Auspex Systems, Santa Clara Lines: 21 >This "bug" has existed since the first NFS I used in SunOS 2.0 and >every version since, including most of the versions based on the >reference port. Given that you'd have to change the protocol to fix that botch, this isn't surprising.... >Last time I looked the reason you get back "-0" "-0"? I take it you have, say, a Univac, sorry, Sperroughs Burrivac, sorry, *Unisys* 1100/2200, or some other one's complement machine? :-) >is that the client side of the NFS VFS does not touch the "f_files" or >"f_ffree" fields of the statfs structure, as a result you get whatever >garbage happened to be in those fields when statfs was called. A >simple fix would be to add two lines of code to zero both fields. Or -1 them, which is what every version of the NFS client-side code I've seen does; perhaps the 2.0-vintage code forgot to assign them values, but the 4.0 code explicitly sets them to -1, and I think this dates back at least as far as 3.0.