We have no idea, and we will never be able to know. They certainly
*CAN*... they are just anonymous 32-bit values.
>
>>Third: If you actually rely on inode numbers to be able to find your
>>files, like most versions of Unix including old (but not current)
>>versions of Linux, then they are completely meaningless.
>
> Agreed.
>
>>There is another way to generate consistent inodes for hard links,
>>which is to use the data block pointer as the "inode number." This,
>>however, has the problem that *ALL* zero-lenght files become "hard
>>links" to each other.
>
> That problem can easily be solved. Simply use different methods
> for zero-length files and all other files. But there might be
> other problems with such an approach:
>
> 1) Could two different files have same data block pointer?
> (different sizes perhaps?)
Theoretically yes.
> 2) Do we need a way to find metadata from the inode number?
Currently we do, but we could rewrite the code not to.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/