[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <62b0912f0608091609q6b3c6c4ev2d287060fa209@mail.gmail.com>
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