linux-ext4 - Re: [PATCH, RFC] ext4: Store basic fs error information in the superblock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100624132745.GH6843@thunk.org>
Date:	Thu, 24 Jun 2010 09:27:45 -0400
From:	tytso@....edu
To:	"Amir G." <amir73il@...rs.sourceforge.net>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH, RFC] ext4: Store basic fs error information in the
 superblock

On Thu, Jun 24, 2010 at 03:09:16PM +0300, Amir G. wrote:
> 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.

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html