Re: ext3 corruption

["Molle Bestefich" <molle.bestefich@gmail.com>]

Duane Griffin wrote:
> It takes into account some of them (such as reading data from the
> backup superblock if it detects corruption). Others will be
> irrelevent for further operations.

Ok, maybe it is accurate?

> Many reports will be accurate

Ok, perhaps not then :-).

I'm still confused as to the performance of "-n".
It would be _very_ good to fix this deficiency in the man page of e2fsck.


Thanks Duane, you've been most helpful.


Jim Crilly wrote:
> > Right.  It's all just "Linux" to me ;-).
>
> Then I guess it's time to break out the learning cap and figure
> out what's what. =)

;-).

You can start by phoning Red Hat.  They call their entire product
"Red Hat Linux", so that pretty much means that "Linux" basically
covers everything, not just the kernel.


> > It's indeed a redhat, though - Red Hat Linux release 9 (Shrike).
>
> Why are you using such an old distribution? I know it's only been 3
> years, but a lot has changed and I don't think anyone supports RH9
> or earlier anymore.

As far as I remember, I configured it to automatically update everything.
Apparently that function just broke itself very early on :-).

I guess the problem is that I don't know a single Linux packaging system
that actually works well enough to keep a system up to date at all times,
and I don't have any free time to spend on reinstalling systems all the
time.

I think most of the package managers break because their dependency system
sucks.  Some of them doesn't suck, but they break because there's no
integrity checks, and package maintainers can dump any kind of bizarre
corrupt dependencies they like into them.  That's how Gentoo works, for
example.  Others have even more bizarre ways of breaking, again Gentoo as
an example requires the user to run a "switch to newer GCC" command from
time to time, otherwise random packages just start breaking.

AFAIK, every single Linux package manager on the planet is half-ass, broken
like above or in some other way.  If you know of one that's actually well
thought through on all planes and well implemented and thus works good enough
to keep a system up to date for three years in a row without human
intervention....
Please speak up!!!


> > (Maybe the kernel SHOULD coordinate it somehow,
> > seems like some of the distros are doing a pretty bad job as is.)
>
> That's pretty much impossible, the best the kernel can do is send
> signals to all of the running processes.

Impossible?  Few things in the software world are impossible.

Surely it's possible to create a kernel interface where processes
can tell the kernel about which other processes they'd like to
outlive and which ones they'd like to get killed before.

The kernel could then coordinate the killing of processes in a
"shutdown" function, which the various distro's 'reboot' and
'shutdown' scripts could call.

And voila, that difficult task of assessing in which order to do
things is out of the hands of distros like Red Hat, and into the
hands of those people who actually make the binaries.

Which is probably a good thing, because

a) Red Hat's init scripts probably fails for me because there's
  something in my setup that Red Hat didn't expect.  A greatly
  simplified system as outlined above would help to fix things
  like this.

b) Less duplicated effort in the form of init script coding for
  the distro maintainers.

I realize that details totally absent in the above, but at least
it doesn't look to me like it's impossible at all.


> ext2 breaks the filesystem up into block groups,

Thanks for the info!

> a wild guess about the error message would be that it couldn't
> find the block bitmap for a certain group

Hmm, I would have expected it to find something completely
corrupt somewhere instead of finding nothing at all.

> or the bitmap that it did find wasn't in the correct group.

Implying that they're linked both ways?
That would probably be a very good thing wrt. recoverability.
Interesting thought!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/