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-next>] [day] [month] [year] [list]
Date:	Thu, 10 Aug 2006 01:09:02 +0200
From:	"Molle Bestefich" <molle.bestefich@...il.com>
To:	"Duane Griffin" <duaneg@...da.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ext3 corruption

Duane Griffin wrote:
> > How close to 1-1 does "-n" relate to non-"-n" ?
> >
> > For example, does e2fsck take into consideration the changes it would
> > have done itself in regular mode when it proceeds to the next problem
> > and/or phase of a -n operation?
>
> It corresponds perfectly to you answering "no" to all questions :)
> Sorry, I don't have a much better answer than that.

A good answer, even if it's one that can be found in the manual :-).

> > If it doesn't, then that command is, well, totally useless.
>
> That is too strong.

I don't think so.

If it doesn't take into account own changes, then the -n command is
unable to produce even a slightly accurate resemblence of what would
happen if I did a real run.

And that's about the only use case I can come up with for -n...

> You should be able to get an idea how severe the damage
> is, at least.

If it's complete inaccurate, I can't trust the result, so that doesn't
help me much, if any.

> From a quick read of the code it looks like your problem
> is related to dodgy data in the superblock, and e2fsck will attempt to
> recover & continue by reading the backup superblock.

Thanks a lot for checking !

I wonder then, will it write back this alternate superblock?

Is there anything I can do to control the process, like:
Do a test mount with one of the alternate superblocks?
Tell fsck to test a specific superblock; afterwards tell fsck to use a
specific superblock?

That would be useful.

> It does that regardless of whether you use -n,
> so in that respect at least it will operate in the
> same way as "normal" operation.

Ok, that's very good to know, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ