> "Albert D. Cahalan" wrote:
>
>> Hans Reiser writes:
>>
>> > Tell us what to code for, and so long as it doesn't involve looking
>> > up files by their 32 bit inode numbers we'll probably be happy to
>> > code to it. The Neil Brown stuff is already coded for though.
>>
>> Next time around, when you update the on-disk format, how about
>> allowing for such a thing?
>>
>> You could have a tree that maps from inode number to whatever
>> you need to find a file. This shouldn't affect much more than
>> file creation and deletion. Maybe it will allow for a more
>> robust fsck as well, helping to justify the cost.
>>
>> It would be really nice to be able to find all filenames that
>> refer to a given inode number.
>
> It would have a significant performance impact and use disk space.
inode numbers have in the past been enough to find the object in the
filesystem, and more than a few applications have counted on this. In my
mind, the difference between an interesting research project and a real
professional grade product is compatibility with these kinds of traditional
expectations.
I think reiserfs has been lucky that we've managed to work around the inode
number problem so far (with help from Neil, Andi and others), but the
number of hours wasted on cramming the 64bit key into various applications
has been huge.
It only makes a speed difference because the original format relies on it.
When redoing the format for v4, this kind of thing should at least be
considered. </soapbox>
-chris
-
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/