I've just heard from a fellow in New Zealand running a completely different
distro (Debian Woody) with a completely different motherboard (some Abit, and
he's running an SMP kernel, so I assume he has an SMP box), yet experiencing
the same 2.4.18+ext3 corruption relationship. I've sent him a message
offering to compare hardware, but have not heard back yet. If I find a
common thread, I'll be sure to let you know. Thus far I don't see anything
we share, but I suspect that if I _do_ find common hardware that will narrow
your focus in addressing this bug. My hearing about his plight has prompted
me to make a further effort to bring this to your attention, as it
strengthens my opinion that this is a bonafide bug at work.
The following is the post I made to the newsgroup:
,--------------- Forwarded message (begin)
Subject: Kernel 2.4.18 + ext3 = filesystem corruption
From: Silvan <silvan@windows-sucks.com>
Date: Fri, 26 Apr 2002 11:08:10 -0400
I had a filesystem explosion (across the board corruption on all ext3
partitions, brought to my attention by a rather nasty series of EXT3_fs
errors and an immediate crash) about a month back. I lost some data, and
there were numerous errors that had to be repaired. I realized that I
couldn't ever remember seeing a fsck since moving to ext3, so I
experimented with tune2fs and dumpe2fs. All of the partitions were set
with a random, large negative number for the maximum mount count. I have
no idea whether that was true before the crash or not.
I began to eliminate suspects. I checked RAM, running memtest 86 for 24
hours with no errors. I reverted to kernel 2.4.16, removed my journals and
mounted ext2, switched to conservative settings all around (lower PCI bus
speed, conservative hdparm options, etc.)
I've been gradually bringing things back to their previous state, fscking my
partitions regularly (daily at first, then gradually moving to a 5 mounts or
7 days interval) as I've gone. I had no filesystem errors of any kind
since the last disaster, and then I decided to move back to 2.4.18. No
problems for a few days, so I installed new journals and moved back to
ext3.
Within four days, I had another filesystem explosion, though it was less
severe than the last, affecting only hde6 and hde9. Files weren't there,
entire chunks of directories were missing, and so on, and everything was
pretty well hosed in that state. Upon recovery, while fscking during the
subsequent boot, there were numerous, numerous errors in the filesystem,
and I've lost more data.
Both crashes were seemingly spontaneous, triggered by everyday activities,
probably brought on when I finally accessed a file that had a hole in it
and brought the whole house of cards tumbling down. I have no record of
anything that happened, as nothing useful made its way into any of my logs.
I'm running Mandrake 8.1 with a generic kernel 2.4.18. No patches. 2.4.16
and 2.4.18 were compiled with the same config, and I don't think there is
anything noteworthy there. Everything works perfectly, except that I
sometimes experience video display corruption when switching virtual
terminals. More a problem with 2.4.16, but it happens with both kernels.
(A separate issue, and not the source of my concern. I'll take video
corruption over data loss any day.)
My hardware:
AMD K7-1000 on ASUS A7V (VIA Apollo KT133a chipset, integrated Promise
ATA-100 controller), 256 MB RAM, Linksys 10/100E NIC, USR PCI Performance
Pro modem, SB PCI 128, Riva TNT2 AGP video (running at 4X in BIOS and in X),
CREATIVE CD-RW RW8439E, CD-950E/TKU, Maxtor 94610H6, generic PS/2 mouse,
generic FD, and a 104-key keyboard.
Kernel boots (LILO) with: append=" devfs=nomount hda=ide-scsi
mem=nopentium"
Partitions are all ext3.
I can think of nothing further to add. I've done my best to isolate this,
but I haven't been able to repeat this in a controlled way so that I can
attribute a precise event as triggering the corruption. It seems that the
corruption is on-going over time while 2.4.18 is running, and eventually I
stumble into a hole. I personally suspect the journaling code, but that's
speculation borne of almost pure ignorance.
`--------------- Forwarded message (end)
-- Michael McIntyre zone 6b in SW VA Silvan Pagan umount /mnt/windows;mke2fs /dev/hde1;tune2fs -j /dev/hde1 www.geocities.com/Paris/Rue/5407/index.html - 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/