linux-kernel - Re: ext3 corruption

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]

Date:	Wed, 9 Aug 2006 17:22:28 +0200
From:	"Molle Bestefich" <molle.bestefich@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: ext3 corruption

linux-os wrote:
> Molle Bestefich wrote:
> > I have a ~1TB filesystem that fails to mount, the message is:
> >
> > EXT3-fs error (device loop0): ext3_check_descriptors: Block bitmap for
>                   ^^^^^^^^^^^_________
>
> It seems as though you have a LOT of RAM if you can make a 1TB
> filesystem on the loopback device!

Why is that?
loop0 is backed by a MD device.

> Seriously, what are you doing, attempting to mount a big file-system
> through the loop-back device

Yes, and it has worked for...  well... many years now.

> or is this a copied-down message message
> you got during boot when initrd tried to mount a RAM disk?

No.

> > group 2338 not in group (block 1607003381)!
> > EXT3-fs: group descriptors corrupted !
>
> Ordinary disk repair involves running fsck on an UNMOUNTED file-system.

It _is_ unmounted.

(I've learned that lesson years ago.  Probably after seeing fsck
complaining loudly when I tried to run it on a mounted filesystem, if
I had to guess ;-).)

> > A day before, it worked flawlessly.
> >
> > What could have happened, and what's the best course of action?
>
> Any bad RAM, any shutdown without a proper unmount, any device hardware
> error like DMA not completing properly, can cause file-system corruption.
> That's why there are tools to fix it.

The hardware works flawlessly.
The shutdown was a regular shutdown -h.

Messages on the console indicated that Linux actually tried to
shutdown the filesystem before shutting down Samba, which is just
plain Real-F......-Stupid.  Is there no intelligent ordering of
shutdown events in Linux at all?

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.

That's what happened on a user-visible level, but what could have
happened internally in the filesystem?
-
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/