On Thu, Apr 13, 2017 at 09:10:19AM -0400, Brian Foster wrote: > IOW, this documentation problem exists because the tool is broken. The > tool will remain broken despite the fact that the problem is documented. > Therefore, we are not just working around a documentation issue by > attempting to improve the tool. I'm not sure that you understood my point. That is, if a developer tool is considered broken, then adding warnings to tell the /user/ the developer tool is broken is not solving the "tool is broken" problem any better than documenting in the man page. The underlying problem is that the log is unobfuscated and so the tool will, by your definition, remain "broken" until that problem is fixed. And, IMO, "broken" is an incorrect classification of the issue. We *chose* not to obfuscate the log because the effort required to implement it falls far, far to the wrong side of the cost-benefit analysis line. Months of work for something that may be relevant only to a developer once or twice a year? Further, bfuscating the log may actually be an unsolvable problem due to the way we do relogging and reuse freed blocks - the obfuscation of log entries has to exactly match the obfuscation that is done on disk, and we may have multiple overwrites of the same directory blocks to obfuscate and all need to be correct. It's a damn hard problem that I'll still strongly suggest we should never attempt to solve. Part of playing the maintainer game is knowing how many resources you have available, the relative complexity of the problems that need to be solved and guiding the use of your limited resources appropriately. Debug tools that are rarely used are at the low end of the priority list - they should have rough edges, because that indicates we spend more time caring about making the production code reliable than we do about polishing tools that are only used when the production code has failed.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
