On Wed, May 14, 2008 at 02:07:14PM -0500, Eric Sandeen wrote: > Aneesh Kumar K.V wrote: > > This helps in better debugging of the problem reported. > > ext4_error happens potentially often in some scenarios, and if I chose > errors=continue I'm not sure I'd want to dump this much. > > Would it be worth limiting how often this goes off (maybe just once per fs?) We should really do an audit of the calls to ext4_error() and determine when it is due to a filesystem corruption (where the stack dump is not useful, and in fact the ext4_error messages should be detailed enough so that it is obvious where the corruption is --- in some cases I've wished that the inode number or block group number where the problem was detected was included) and where it is more of an assertion failure, where the stack dump is useful. If there seems to be a need to include dump_stack(), the first question I would ask is whether ext4_error() was really the right way of flagging a problem in the first place, as opposed to using a WARN() or WARN_ON(). The same is true for ext4_warning(). There should be a very clear distinction between filesystem corruption, I/O errors, and programming faults, as much as possible. - Ted -- 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
