Subject: Re: inode numbers, was filehandles
To: Simon Burge <simonb@NetBSD.ORG>
From: Bill Studenmund <firstname.lastname@example.org>
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? :-)