On Saturday, June 21, 2014 6:06:00 PM PDT, Dave Chinner wrote:
BTW, it's worth noting that reviewers are *allowed* to change their mind at any time during a discussion or during review cycles. Indeed, this occurs quite commonly. It's no different to multiple reviewers disagreeing on what the best way to make the improvement is - sometimes it takes an implementation to solidify opinion on the best approach to solving a problem.
The issue I have is not that you changed your mind per se, but that you were right the first time and wrong the second time. As you know, reviewers are not just allowed to change their minds but are also allowed to be wrong from time to time. The reason that you were wrong the second time is not that the interface you proposed is wrong - I believe that we violently agree about superblock-based writeback as the correct approach long term - but that the current, inode based writeback already works well enough for our needs. It therefore makes exactly zero sense to go off on a tangent to engineer a new core mechanism at the same time as merging the filesystem. The correct way to do it is to get a likely user into kernel first (Tux3) and then engineer the new interface that will be so all-dancing that you will immediately feel compelled to adopt it for XFS. Obviously, with only one user of the imperfect/functional interface the maintenance overhead of updating it to the new perfect/amazing interface rounds to zero. Remember, this is an _internal_ API, so the do-not-break rule simply does not apply. Instead, the "perfect is the enemy of good enough" rule is operative. Just to reiterate for the tl;dr amongst us: you were right the first time. Go ahead and change your mind, but when you finally realize that you were wrong the second time, please do let us know. Meanwhile, we must concentrate on the upcoming page forking hooks, which promise to provide even more scope for being both right and wrong, and smart or stupid about which parts of the kernel should be deeply re-engineered versus prudently adapted to evolving needs. Regards, Daniel -- 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
