>> 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. Z -- 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
