On Thu, Apr 21, 2011 at 3:58 PM, Zenon Panoussis <oracle@xxxxxxxxxxxxxxx> wrote: > >>> It needs to be populated first before being efficient. And it'll be >>> less efficient now that you populate it with extra entries. > > At the risk of being run out of town covered in tar and feathers, I'll > venture voicing the opinion of an end-user who doesn't know ceph, is not > a developer, and doesn't even understand half of the technicalities of > this discussion. > > From my end-user point of view, efficiency is great and very desirable, > but is still secondary. Simplicity of code and the reduction of bugs that > comes with it is great and adds elegance to intelligence, but is still > secondary. The safety of data though, now, that is primary and above > everything else when it comes to a file system. A file system's *only* > purpose is to store and retrieve data. Efficiency and speed are features, > positive qualities that make a file system better, but only as long as > it actually can fulfil its purpose of storing and retrieving data without > losing or corrupting them. > > Looking at it this way, the potential of a hash collision is catastrophic > no matter how small it might be. The measure of this problem is not the > objective likelihood that it will occur, but the subjective level of worry > that it might occur. Simply put, even if there's one chance of a hash > collision in 10 billion and I only have a couple of million files, I still > end up being unable to trust the integrity of *any* of them. > > One might argue here that no file system in this world offers a 100% file > integrity guarantee. That's absolutely true, but it is and should remain > a shortcoming and not be elevated to an intentional design feature. > We fully understand your worry, and in any case with the hashing solution it doesn't mean that when there's a collision you lose the data, just that the data lookup needs to traverse more objects. HTH, Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
