Re: Better Linux Kernel Patch for 4GB Inode Problem

[Paul Serice <paul@serice.net>]

> It just has other bugs...
>
> 	It assigns inode number 0 to all zero sized files
> 	as fdar as I can see.

What do you know about that!  I knew it was theoretically possible to
assign the same inode number to two files, but I really didn't think
it would happen for a common case.  :-(

I never posted here my first attempt at altering the inode numbering
scheme.  It used a red-black tree to map a particular file to a
particular inode number.  I think it guaranteed unique inode numbers,
I had to give up on it because it consumed too much memory.

I'm not even sure it's possible to guarantee unique inode numbers
without some sort of map.  For example, I just took a quick look at
the NetBSD cd9660 file system.  For non-directories, it appears to use
the lower 32-bits of the byte offset of the directory record for the
file as the inode number.  For directories, it looks like it uses the
same inode number I do except it shifts it left.

I know "ls" and "find" require each directory to have a unique inode
number in order to recurse properly, and I think I provide this.  On
the other hand, the current linux code cannot provide this, and the
NetBSD code appears to not provide this either.  So, I think I'm
making progress.

For non-directories, it's another story.  I think I'm no better or
worse than the current linux code or the NetBSD code.  I'm o.k. with
it (for now) because I just don't know of any commonly used programs
that might break.  So for now, I'm willing to make the trade off of
low kernel memory consumption for having non-unique inode numbers for
zero-length files.

Don't get me wrong, I'd be happy to rewrite things to guarantee
unique inode numbers if someone else can put forward how to proceed.