lkml.org 
[lkml]   [1998]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ext2 corruption in 2.0.33
On Mon, 26 Jan 1998, Theodore Y. Ts'o wrote:

> There has been exactly one other such report (although unfortunately I
> don't have the kernel version number) from Nick Holloway
> (Nick.Holloway@alfie.demon.co.uk) on September 30, 1997.
>
> My guess then, and it remains the same, since if there was a problem
> with the kernel we should have seen a lot more complaints than just
> these two isolated reports in over six months, was a hardware or DMA
> glitch which caused data to get written to the wrong place.
>
> It's possible that it could be a kernel problem, though, which is why I
> do keep track and file such reports when people raise them, in order to
> find patterns if they exist. So I'll file your report and see if anyone
> else reports these problems (I track linux-kernel and
> comp.os.linux.development.system looking for such bug reports.)
>
> - Ted

I have seen a strange filesystem corruption while we were working on
the RAID-5 reconstruction support back in September/October (2.0.31).

The RAID reconstruction thread runs the following loop:

for (each block) {
bh = bread(block); /* serviced using the operational drives */
mark_buffer_dirty(bh); /* writes will be serviced by all drives */
}
fsync_dev(...);

The reconstructed filesystem had a very interesting corruption pattern;
one block in an inode table was overwritten with an increasing:

0 1 2 3 4 5 .. 127

byte pattern, which was repeated on each 128 bytes boundary (every inode)
in the block. I recall that I tried to reproduce it, without success.

Gadi

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.091 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site