linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: maney@two14.net (Martin Maney)
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: linux-kernel@vger.kernel.org
Subject: 2.4.22-rc2 ext2 filesystem corruption
Date: Mon, 11 Aug 2003 22:58:03 -0500	[thread overview]
Message-ID: <20030812035803.GA17921@furrr.two14.net> (raw)


Okay, further testing is clearly indicated (and I'm recompiling a test
kernel while writing this to try to narrow it down a little), but I've
got a very repeatable file corruption under 2.4.22-rc2 that does not
manifest under 2.4.21.  My repeatable test case only (so far?) causes
the data in the file to be corrupted, but I suspect metadata can get
hit as well, and I have seen some filesystem errors that were probably
caused by this, but not so that I can say so with certainty.

The recipie is simple: cp a large file across filesystems.  All looks
well (md5sums match, etc), but the file is all still present in memory. 
But if you then unmount the destination filesystem to invalidate the
buffers, after mounting the file data will have changed.  I'm pretty
certain that I have observed the same effect without the mass
invalidation of umount in a couple of cases, but I haven't replicated
that.

In all cases I have investigated, the corruption seems to take the form
of four bytes of garbage at the beginning of a block; two small scripts
have been observed with 4 NULLs prepended and the last four characters
truncated.  In another case I found a block of over 100 bytes (I got
tired of wading through it after a while) in the same form - four bytes
were inserted into the corrupted file, pushing the data back.  In
hindsight I wish I had investigated that case further; as it is, I'm
not positive the dislocation was at a disk block boundary.

(I have one example I saved that appears NOT to begin at a block
boundary, with a dislocation that continues for at least 8KB (by spot
checking of cmp --verbose output).)

The machine is a PIII/850 on an Asus 440BX board with a Promise 20265
controller; the Seagate ST340016A is the only device connected to the
Promise's ports.  There's 640MB of ECC'd memory on board, and I haven't
had an SBE reported on this system in a year or so (the last hardware
changes was two or three months ago).  (I disabled the ECC monitoring
module while verifying this problem; made no difference.)

The "large file" I've been using (becuase it was where I first observed
an issue) was the XFree86 4.2.1 source archive.  At 54MB, it is less
than 1/10th the size of physical RAM.

-- 
There is nothing perhaps so generally consoling to a man as a
well-established grievance; a feeling of having been injured,
on which his mind can brood from hour to hour, allowing him
to plead his own cause in his own court, within his own heart,
and always to plead it successfully.  -- Anthony Trollope


             reply	other threads:[~2003-08-12  3:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-12  3:58 Martin Maney [this message]
2003-08-12 10:18 ` 2.4.22-rc2 ext2 filesystem corruption Stephan von Krawczynski
2003-08-12 13:12 ` Marcelo Tosatti
2003-08-12 13:42   ` Martin Maney
2003-08-12 14:10     ` Marcelo Tosatti
2003-08-12 15:14       ` Martin Maney
2003-08-12 16:58         ` Marcelo Tosatti
2003-08-12 17:11           ` Alan Cox
2003-08-12 16:56       ` Martin Maney
2003-08-12 17:09         ` Marcelo Tosatti
2003-08-12 21:36           ` Martin Maney
2003-08-13 11:28             ` Alan Cox
2003-08-13 11:37               ` Stephan von Krawczynski
2003-08-13 14:55             ` Marcelo Tosatti
2003-08-13 18:13               ` Martin Maney
2003-08-13 19:40                 ` Alan Cox
2003-08-16  6:35                   ` Martin Maney
2003-08-17  0:09                     ` Mike Fedyk
2003-08-13 22:58                 ` Nerijus Baliunas
2003-08-12  6:20 Alex Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030812035803.GA17921@furrr.two14.net \
    --to=maney@two14.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maney@pobox.com \
    --cc=marcelo@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).