Re: Better Linux Kernel Patch for 4GB Inode Problem

[Paul Serice <paul@serice.net>]

> This is definitely not allowed!
>
> In short: POSIX requires that each unique file on a system has a unique
> st_dev/st_ino pair.

I understand, but the current code is, in most ways, much further from
the standard than my patch.



> Well I thought that I did point you to a decent algorith with your
> first patch.... when I said that the facts it was based on are
> correct but the asumptions made from the facts have been based on
> wrong math. If you just fix the math bugs in the first patch, you
> would get a much better inode algorithm.

I definitely appreciate the hints.  The closest I came to figuring it
out is that I rounded down to 60.  Given that the kernel code goes to
great lengths to splice together blocks, at the very least, I should
have rounded up to 61.  I didn't think this is what you were hinting
at though because at 60 or 61, I should still have unique inodes
because both fit in 6 bits.  I thought you were hinting at something
deeper.  Something I was never going to be able to figure out.

I figured you were doing me a favor from a licensing standpoint by not
disclosing more of the solution.  So, I didn't want to bother you
further.  Plus, I was never entirely happy with the first patch I
posted.  It has the same problems as the current kernel code just at
128GB instead of at 4GB.  So at some point in the not too distant
future, the code was going to break again.

By the way, if you don't mind my asking, what was the problem with
the first patch?