Re: 2.4.20-rc3 ext3 fsck corruption -- tool update warning needed?

Theodore Ts'o (tytso@mit.edu)
Mon, 25 Nov 2002 21:47:39 -0500


On Mon, Nov 25, 2002 at 12:12:55AM -0500, Clemmitt Sigler wrote:
> I'd been running 2.4.20-rc3 for two days. While rebooting it tonight
> fsck.ext3 corrupted my / partition during an automatic fsck of the
> partition (caused by the maximal mount count being reached). (I had
> backups so I was able to recover :^) The symptoms were that some files
> like /etc/fstab and dirs like /etc/rc2.d disappeared -- not good.
>
> My system is Debian Testing, with Debian e2fsprogs version
> 1.29+1.30-WIP-0930-1. I use ext3 partitions with all options set to
> the defaults (ordered data mode). This is an SMP system, in case
> that matters. Please e-mail me for any other details that might help.
>
> I'm wondering if this change between -rc1 and -rc2 might be a factor ->
>
> <tytso@think.thunk.org>
> HTREE backwards compatibility patch.

Nope; I really doubt it. All the HTREE compatibility patch does is
clear the INDEX_FL flag in a directory inode if the directory inode is
modified. It's a very, very innocuous patch.

> Upon rebooting to 2.4.19 (SMP kernel also), the system did another
> auto-fsck.ext3, this time on /usr. I held my breath, but all went fine.
> This seems to me to narrow it down to a kernel/e2fsprogs incompatibility
> (but I'm not an expert).

Well, no; it could also be that some kind of filesystem corruption
either made the directories disappear, or caused e2fsck to believe
that the files needed to be removed or moved into lost+found. There
are a million possible explanations, including a bug in a device
driver, the VM layer, or just pure coincidence.

Without some clear indication of what e2fsck actually printed we'd
only be speculating.

> If this is indeed the case, please put a LOUD WARNING in the kernel
> notes that some versions of e2fsprogs are incompatible. HTH.

No, there shouldn't be any kind of compatibility problems. All of the
various extensions to ext2/ext3 are all clearly marked with feature
flags in the superblock, and need to be explicitly enabled before they
take effect.

Can you can duplicate the problem?

- Ted
-
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/