On Wed, Mar 14, 2012 at 10:28:20AM -0400, Phillip Susi wrote: > > 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. I don't think the choice is obvious. A solution which solves the problem 90% plus of the time for real-life workloads, without requiring any file system format changes, is very appealing to me and to I think many customers. That being said, for someone who is looking for perfection, I can see how it would grate on someone's nerves. > 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. The original htree implementation tried very hard to be fully backwards compatible for reading and writing. At the time that was considered very important, and for some folks it was a major killer feature. The original ext3 journalling support was designed in a way where you could back out and mount such a file system on an ext2 file system, and that was considered important back then, too. The fact that we've been so successful with ext4's upgrade to features that require RO_COMPAT or INCOMPAT features does make me more willing to consider those features, but the reality is that the deployment time for such a new feature is measured in 2-3 years, minimum. So I won't rule out making such a change, but I wouldn't let the fact that someone wants to sign up to implement a long-term feature, to be mutually exclusive with a short-term solution which solves most of the problem that could be rolled out much more quickly. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
