Subject: Re: inode numbers, was filehandles
To: Simon Burge <simonb@NetBSD.ORG>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: tech-userlevel
Date: 12/07/1999 12:36:19
On Tue, 7 Dec 1999, Simon Burge wrote:

> Ok, let's get back to NFS.  At the moment, all local filesystems for
> NetBSD have u_int32_t (or smaller?) as the inode type, so the basic
> stat(dev,inum) test for file equivalence works.  It's only where you've
> NFS mounted a remote filesystem that has > 2**32 inodes that we have a
> problem, correct?  From my reading of the NFS code, NFSv3 supports 64
> bit fileids, so simplistically why not just make ino_t a 64 bit value?
> The way disk sizes are increasing, it's something that we may have to do
> sooner than later anyways...

Disk size doesn't have much to do with it. It's file count that matters.
:-)

To go with a larger file count, we need a different filesystem. AFAIK, the
only filesystems which support 64-bit inode numbers are xfs and hfs+.

Bumping the size of ino_t would be nice, but we'd need to audit all of the
existing usages to make sure that they are ok. For instance, ino_t in
on-disk data structures would need to be chaged.

We'd also need to version the stat calls.

Interested in it? :-)

Take care,

Bill