NFS on 3030

[Brendan Eich]

>      I have another question about NFS.  I have been told that SGI NFS uses
> a signed 16 bit number for inodes, thus limiting the total number of inodes
> to 32767.  Our Gould sets up disk space with 2048 bytes/inode, thus an NFS
> mount is limited to 64M bytes.  Has this given anyone problems?  Has SGI
> fixed this problem?

SGI 3000 series Unix, based on AT&T System 5.0, uses the traditional 16
bit unsigned inode number representation.  The 4D series uses an unsigned
32 bit representation.  In neither case does the representation *limit*
the total number of inodes which a client may access from a Gould, Sun,
or BSD-based server.

NFS, to be NFS, must follow the protocol standard and use an XDR
unsigned long for the filesystem node identifier (same as inode number
for Unix servers).

The problem (much commented upon) with inumbers is what representation
stat(2) uses.  Stat must not chop any bits from NFS inumbers, or
pwd(1) and its ilk may be confused.  Release 3.5 of the 3000 series
software returned only the low 16 bits of NFS inumbers, causing occasional
pwd failure.  Release 3.6 of 3000 series software contains a new version
of stat that returns 32 bits of inumber.  The kernel and local filesystem
(EFS) still use the old System 5.0 16 bit representation.  The 4D kernel
uses 32 bits everywhere.

In short, release 3.6 for the 3000, and all 4D versions of NFS suffer no
NFS inode number bugs.

Brendan Eich
Silicon Graphics, Inc.
brendan at sgi.com