inodes on remote disks (was: running out of inodes?)

[David Robinson]

In article <TALE.89May20111826 at imagine.pawl.rpi.edu> tale at pawl.rpi.edu writes:

<This is on a tangent, but here is something that has been noticed on
<our SunOS 4.0.1 system:

<Filesystem             iused   ifree  %iused  Mounted on
</dev/xy0a                620    1428    30%   /
<life.pawl.rpi.edu:/usr
<                           0      -1    -0%   /usr
</dev/xy1h              10047   18625    35%   /appl/imagine2
<rpi.edu:/usenet            0      -1    -0%   /usenet
[...]
<
<The thing that puzzles us in the curious data for any remote
<filesystem; my first wild guess was that the information from the
<remote disk couldn't be found by the local df.  The problem with that
<wild guess, from my perspective, is that it used to work fine under
<SunOS 3.5.  Now are users get absolutely no useful information
<regarding inodes when they are on the diskless Suns; in the case of
</usenet, at least, the information can sometimes be useful to people
<who don't really have any control over the disks.

This bug is an artifact of the NFS protocol revision 2, it has a statfs()
remote procedure call that does *NOT* return the number of files 
available or free.  In the latest draft of NFS rev 3 I saw
(dated Feb 89) the number of files available and free are
returned from a statfs remote procedure.

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.  Last time I looked the reason you get back "-0" 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.

-- 
	David Robinson		elroy!david at csvax.caltech.edu     ARPA
				david at elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!