On 3/13/2012 5:33 PM, Ted Ts'o wrote:
Are you volunteering to spearhead the design and coding of such a thing? Run-time sorting is backwards compatible, and a heck of a lot easier to code and test...
Do you really think it is that much easier? Even if it is easier, it is still an ugly kludge. It would be much better to fix the underlying problem rather than try to paper over it.
The reality is we'd probably want to implement run-time sorting *anyway*, for the vast majority of people who don't want to convert to a new incompatible file system format. (Even if you can do the conversion using e2fsck --- which is possible, but it would be even more code to write --- system administrators tend to be very conservative about such things, since they might need to boot an older kernel, or use a rescue CD that doesn't have an uptodate kernel or file system utilities, etc.)
The same argument could have been made against the current htree implementation when it was added. I think it carries just as little weight now as it did then. People who care about the added performance the new feature provides can use it, those who don't, won't. Eventually it will become ubiquitous.
We would still have to implement the case where hash collisions *do* exist, though, and make sure the right thing happens in that case. Even if the chance of that happening is 1 in 2**32, with enough deployed systems (i.e., every Android handset, etc.) it's going to happen in real life.
Sure it will happen, but if we read one extra block 1 in 4 billion times, nobody is going to notice.
-- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
