> 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?
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
