Hi,
thanks to all who responded
"Freesmeyer, Mary" <Mary.Freesmeyer_at_LendersService.com>
dsr_at_mail.lns.cornell.edu (Daniel S. Riley)
alan_at_nabeth.cxo.dec.com
The maim result is that I may not worry about this behavior because
NFS does not know about the inodes. For more details I include
the answers from Daniel and Alan
Regards
Otto
PS: But the explanations cannot be the whole truth. There is an inconsistency.
Node2 (V4.0, NFS , mounted disk) shows for
/usera the zero numder of inodes
but for another disk
/userb the correct number as reported on Node6 to which the is is local
Both disks disks are of the same type, installed at the same time...
Also for the other following NFS mounted disk (locally to Node6) Node2
gives the correct information. The disk with the wrong result (/usera)
is the first one NFS disks in the df listing.
(But maybe one should not try do understand everything)
----------------------------------------------
Daniel S. Riley wrote:
NFSv2 vs. NFSv3? "inodes" doesn't really make sense over NFS, which
knows nothing about the structure of the remote filesystem. NFSv2 has
no way at all of reporting the number of inodes--the entire NFSv2
statfs structure is just:
struct nfsstatfsok {
u_int fsok_tsize; /* preferred transfer size in bytes */
u_int fsok_bsize; /* fundamental file system block size */
u_int fsok_blocks; /* total blocks in file system */
u_int fsok_bfree; /* free blocks in fs */
u_int fsok_bavail; /* free blocks avail to non-superuser */
};
so that's all df has to go on. NFSv3 added "file slots" to the v3
equivalent of the statfs structure, and unix systems typically
translate "file slots" to inodes. Hence:
dsr_lns130% mount
[...]
lns598:/nfs/cmpgrp on /a/lns598/nfs/cmpgrp type nfs (v2, rw, nosuid, nodev, udp, hard, intr, wsize=8192, rsize=8192)
lns101:/nfs/homes/cleo on /a/lns101/nfs/homes/cleo type nfs (v3, rw, nosuid, nodev, udp, hard, intr, wsize=8192, rsize=8192)
dsr_lns130% df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
[...]
lns598:/nfs/cmpgrp 0 0 0 0% /a/lns598/nfs/cmpgrp
lns101:/nfs/homes/cleo
2049662 407459 1642203 20% /a/lns101/nfs/homes/cleo
Note the zeroes for the v2 mount, non-zero for the v3 mount.
> But I still can copy files from Node2 to that particular disk.
NFS doesn't know or care about the details of the remote filesystem,
so it doesn't check the number of inodes. If there are insufficient
free inodes, it is the job of the server to translate that to an
appropriately generic NFS error when file creation fails.
Alan wrote:
Since the particular file system is at the other end of an
NFS mount, either the server is lying to the host about
how many "inodes" there are, or the client is mis-interpreting
what the server is telling it. Since the client with the
problem is the oldest V4 release, I would guess it is a bug
on the client side. You may want to upgrade that system to
a modern version, especially since V4.0 through V4.0C are
not Year 2000 friendly.
----------------------------------------------------------
The original question was:
I get a zero number of inodes with df from one node or at least different
between nodes. How can I understand this:
#df -i
Filesystem 512-blocks Used Available Capacity Iused Ifree
%Iused Mounted on
Node6: (V4.0d)
rz9g#usera 8690144 4888342 3766944 57% 2437 6435484
0% /usera
Node4: (V4.0b)
/usera_at_linix6 8690144 4888342 3766944 57% 2437 6435484
0% /usera
but Node2: (V4.0)
/usera_at_linix6 8690144 4888342 3766944 57% 0 0
0% /usera ^^^^^ ^^^^
But I still can copy files from Node2 to that particular disk.
Any idea?
Regards
Otto
-------------------------------------------------------------------------
| Dr. Otto Titze, Kernphysik TU, Schlossgartenstr. 9, D-64289 Darmstadt |
| titze_at_ikp.tu-darmstadt.de Tel: +49(6151)16-2916,FAX:16-4321|
-------------------------------------------------------------------------
Received on Thu Jan 06 2000 - 07:57:00 NZDT