[I've moved this to tech-kern - it now firmly on the kernel side ]

Charles M. Hannum wrote:

> Bill Studenmund <wrstuden@nas.nasa.gov> writes:
>
> > 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+.
>
> This only affects directory entries, and it would be very easy to
> switch the behavior automatically based on total number of inodes in
> the file system.  (Might cause some issues with fsresize, but that
> seems to have sputtered out anyway.  B-))

We don't have xfs or hfs+ at this stage, so this is a moot point now.
Perhaps more interesting is 64 bit inode support in ffs/lfs but I don't
have any gems of enlightenment on that.  Let's see - 2*32 inodes will
take up 512GB of disk on their own - maybe this won't be a problem in
the near term.  Even so, directory handling looks like it would get very
ugly very quickly.

> Of course, a bunch of system calls would have to be versioned, and
> we'd have to come up with a consistent, defined behavior for what
> happens when you hit a `large' inode number with an old (or emulated)
> system call...

Just returning the lower 32 bits of the inode number seems like the only
option, doesn't it?  It appears that this is what the current NFSv3 code
does when it recieves a > 2**32 fileid anyway.  Has any actually tested
our NFSv3 stuff against a filesystem with > 2**32 inodes?

Bill also wrote:

> 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.

At a glance, only the lfs superblock uses ino_t - all other uses appear
to be in memory.


I'll play around some and see what happens...

Simon.