Re: ext3 corruption

From: Jim Crilly
Date: Wed Aug 09 2006 - 23:46:56 EST

On 08/09/06 08:28:34PM +0200, Molle Bestefich wrote:
> Michael Loftis wrote:
> >> Is there no intelligent ordering of
> >> shutdown events in Linux at all?
> >
> >The kernel doesn't perform those, your distro's init scripts do that.
> 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. =)

> (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. If anything requires anything more
complicated (and many do) then even worse things will happen.

> >And various distros have various success at doing the right thing. I've
> >had
> >the best luck with Debian and Ubuntu doing this in the right order. RH
> >seems to insist on turning off the network then network services such as
> >sshd.
> Seems things are worse than that. Seems like it actually kills the
> block device before it has successfully (or forcefully) unmounted the
> filesystems. Thus the killing must also be before stopping Samba,
> since that's what was (always is) holding the filesystem.
> 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

> >> Samba was serving files to remote computers and had no desire to let
> >> go of the filesystem while still running. After 5 seconds or so,
> >> Linux just shutdown the MD device with the filesystem still mounted.
> >
> >The kernel probably didn't do this, usually by the time the kernel gets to
> >this point init has already sent kills to everything. If it hasn't it
> >points to problems with your init scripts, not the kernel.
> Ok, so LKML is not appropriate for the init script issue.
> Never mind that, I'll just try another distro when time comes.
> I'd really like to know what the "Block bitmap for group not in group"
> message means (block bitmap is pretty self explanatory, but what's a
> group?).

ext2 breaks the filesystem up into block groups, a while guess about the
error message would be that it couldn't find the block bitmap for a certain
group or the bitmap that it did find wasn't in the correct group.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at