On Thu, Jun 24, 2010 at 4:27 PM, <tytso@xxxxxxx> wrote: > True, thanks for pointing that out; the simplest way to solve this for > my purposes is to snapshot those superblock fields and restore them > after replaying the journal. > I guess that should work. I wonder why the ERROR_FS flag is not snapshotted on mount and the file system relies on the journal abort flag to re-set the ERROR_FS. > I wonder if the a better solution for this > particular use case is much larger ring buffer, and a hook into the > printk system which is guaranteed to record *everything*, even after a > panic or after the journal has been aborted and the file system has > been remounted read-only. > sounds like a good feature which would be hard to implement... BTW, I think that if the file system error behavior is set to "remount-ro" a file system with ERROR_FS, should be remounted read-only on mount time. this is the only way to prevent a file system from getting over corrupted and I don't see why there is no way to enforce this with existing error behavior options. We've implemented this logic at application level in our appliances. > For the patch I wrote, my intention was as a supplement to > /var/log/messages --- where s_first_error_time might be from long > after /var/log/messages had rolled over. So I was trying to solve a > somewhat different problem. (Hmm, actually, it would probably be good > to save both details about the first as well as the most recent error.) > One thing that is missing from the error info is its severity level. If I would have to save just one error info, it would be the first error after fsck (i.e. transition from healthy to sick file system), but I would override it if a message of higher severity occurs. Amir. -- 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
