Frank Mayhar wrote: > On Fri, 2009-12-11 at 14:02 -0600, Eric Sandeen wrote: >> My first thought was that this was a bandaid too, but I guess it can >> come about due to on-disk corruption for any reason, so it should >> be handled gracefully, and I suppose this approach seems fine. > > That's why we've been running with it, yes. now if this is coming about as the result of a programming error, we'd better sort that out ;) Do you have any reason to believe that the corruption a hardware or admin issue, vs. an actual bug somewhere? >> Since this is catching on-disk corruption, though, it'd be better to call >> ext4_error() and let the mount-time error-handling policy decide what to do. >> >> I like having more info but below seems awfully wordy ;) Maybe the first >> printk would suffice, and switching it to an ext4_error() would be best, >> I think. > > Okay, I'll rework the patch a bit and resubmit it. Thanks! The amount of info printed is probably just a judgement call; for a developer, printing out the inode & iblock is enough 'cause we can then just go use debugfs & look at it. For a bug report, perhaps more info would be useful because that one set of printks may be all we'll get ... up to you. Maybe we should think about a generic "print corrupted inode information" infrastructure that could be reused ... Thanks, -Eric -- 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
