On Thu, 9 Dec 1999, Simon Burge wrote:

> Charles M. Hannum wrote:
> 
> > Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> >
> > 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.

hfs+ mightn't be that bad. Darwin's hfs+ uses a vnode layer which looks
like the 4.4 one, so porting that wouldn't be too bad. While it raises the
APSL question, it doesn't have the GPL virus problems (APSL, the Apple
Public Source License, is kinda like GPL in that Apple gets changes and
can make them open source. It differs from GPL in that it doesn't say
anything about the other files it's linked with).

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

Sounds good.

Take care,

Bill