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] [day] [month] [year] [list]

Message-ID: <AANLkTiknXLzOHuYZny1wkQ0b7TGwUOjkGA3RZO88Uc6f@mail.gmail.com>
Date:	Sat, 26 Jun 2010 04:16:36 +0300
From:	"Amir G." <amir73il@...rs.sourceforge.net>
To:	tytso@....edu
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 4:27 PM,  <tytso@....edu> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html