On Fri, Jan 25, 2013 at 10:09:48AM -0500, Theodore Ts'o wrote: > On Fri, Jan 25, 2013 at 10:22:44AM +0100, Lukáš Czerner wrote: > > > > we can get the EIO error from ext4_map_blocks not only in the case > > of hardware error. The extent tree might not be in consistent state, > > or we could even ask for blocks outside the file system itself (I > > believe I've seen this before) and I think that in those cases it > > might be worth to all WARN_ON. > > Sure, but in those cases, the file system is corrupt, and we should > have thrown an ext4_error() in ext4_map_blocks(). The point is that a > WARN_ON is only useful if there is a potential programming bug. If we > know for sure that it's caused by a file system corruption, then we > don't want to throw a WARN_ON. FWIW, XFS handles this problem with an error level sysctl. For situations like this, the default level doesn't throw stack traces (just the error message), but there are situations where diagnosis requires emitting the stack trace. Hence if it is necessary for bug triage, users can then turn the sysctl up to 11 and the stack trace will be emitted after the warning message. CONFIG_XFS_DEBUG sets the default log level to 11, because developers always want to know where an error came from ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
