linux-ext4 - Re: ext4_clear_journal_err: Filesystem error recorded from previous mount: IO failure

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: <201010240220.46113.bs_lists@aakef.fastmail.fm>
Date:	Sun, 24 Oct 2010 02:20:45 +0200
From:	Bernd Schubert <bs_lists@...ef.fastmail.fm>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	Amir Goldstein <amir73il@...il.com>, linux-ext4@...r.kernel.org,
	Bernd Schubert <bschubert@....com>
Subject: Re: ext4_clear_journal_err: Filesystem error recorded from previous mount: IO failure

On Sunday, October 24, 2010, Bernd Schubert wrote:
> On Sunday, October 24, 2010, Ted Ts'o wrote:
> > On Sat, Oct 23, 2010 at 07:46:56PM +0200, Bernd Schubert wrote:
> > > I'm really looking for something to abort the mount if an error comes
> > > up. However, I just have an idea to do that without an additional
> > > mount flag:
> > > 
> > > Let e2fsck play back the journal only. That way e2fsck could set the
> > > error flag, if it detects a problem in the journal and our pacemaker
> > > script would refuse to mount. That option also would be quite useful
> > > for our other scripts, as we usually first run a read-only fsck,
> > > check the log files (presently by size, as e2fsck always returns an
> > > error code even for journal recoveries...)  and only if we don't see
> > > serious corruption we run e2fsck. Otherwise we sometimes create
> > > device or e2image backups.  Would a patch introducing "-J recover
> > > journal only" accepted?
> > 
> > So I'm confused, and partially it's because I don't know the
> > capabilities of pacemaker.
> > 
> > If you have a pacemaker script, why aren't you willing to just run
> > e2fsck on the journal and be done with it?  Earlier you talked about
> > "man months of effort" to rewrite pacemaker.  Huh?  If the file system

Hmm, maybe we have a mis-understanding here. If we could make e2fsck to *only* 
recovery the journal, that would be perfect. Kernel and e2fsck journal 
recovery should take approximately the same time. But that option does not 
exist yet (well, a half baken patch is on my disk now). If e2fsck then would 
detect as the kernel:
"clear_journal_err: Filesystem error recorded from previous mount" 
and mark the filesystem with an error, that would be all we need to then abort 
the mount in the pacemaker script and allow us to run a real e2fsck outside of 
pacemaker.


Thanks,
Bernd
-- 
Bernd Schubert
DataDirect Networks
--
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