On Thu, Jun 24, 2010 at 03:09:16PM +0300, Amir G. wrote:
quoted text
> Hi Ted,
> 
> I saw your patch to store fs error information in the superblock.
> I think it is a very useful feature and I have implemented something similar in
> next3_snapshot_journal_error.patch and e2fs_next3_message_buffer.patch
> (attached).
> 
> There is one big problem I encountered with this feature:
> If the file system error behavior is set to "abort" or "remount-ro",
> the journal recovery on the next mount will most likely write over the
> superblock with the errors information.

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.

quoted text
> To solve this problem I stored the errors message buffer in the
> journal superblock
> and copied the message buffer to the filesystem superblock on journal
> recovery (both on mount and fsck).
> fsck also displays the errors buffer and clears it.

That's an interesting approach, although as you point out it only
works on file systems with a 4k block size.  Your design seems to be
focused on recording only the most recent logs, which makes sense in a
debugging environment.  My assumption was that the most recent
problems would probably be recorded in /var/log/messages, although if
the problem occurred on a single-disk system, that assumption probably
wouldn't hold true.  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.

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.)

   	     	     	       	     	     - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html