tale@pawl.rpi.edu (David C Lawrence) (05/20/89)
In article <17641@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
Chris> On modern systems, simply run `df -i'.
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
/dev/xy1e 43257 32519 57% /home
/dev/xy0h 24785 28463 47% /appl/imagine1
/dev/xy0e 194 1854 9% /var
/dev/xy1a 602 1446 29% /var/spool/mail
/dev/xy0d 5970 43182 12% /export
rpi.edu:/usenet 0 -1 -0% /usenet
hope.its.rpi.edu:/itss_b
0 -1 -0% /itss_b
hope.its.rpi.edu:/itss_c
0 -1 -0% /itss_c
life.pawl.rpi.edu:/appl/life1
0 -1 -0% /appl/life1
life.pawl.rpi.edu:/usr/local
0 -1 -0% /usr/local
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.
Can someone please tell me why this is like this?
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))
(error "UUCP not spoken here. Long bang paths unlikely to get mail replies.")david@elroy.Jpl.Nasa.Gov (David Robinson) (05/21/89)
In article <TALE.89May20111826@imagine.pawl.rpi.edu> tale@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@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!guy@auspex.auspex.com (Guy Harris) (05/23/89)
>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.