From: Eric Sandeen <sandeen@sandeen.net>
To: Jeffrey Merkey <jeffmerkey@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: EXT3 File System Corruption 2.6.34
Date: Mon, 07 Jun 2010 15:59:57 -0500 [thread overview]
Message-ID: <4C0D5DCD.5010201@sandeen.net> (raw)
In-Reply-To: <AANLkTinQatQEYahpkN3bT-S5C41HqRoH--gTrvIbGs_c@mail.gmail.com>
Jeffrey Merkey wrote:
> Still seeing file system corruption after journal recovery in EXT3.
> It's easy to reproduce, though the symptoms vary. One way is to
> rebuild a program and while the program is being compiled just shut
> off power to the system by pulling the plug. I am seeing the
> /root/.viminfo file trashed after recovery if Vim was active during
> poweroff. I am also seeing object modules getting built which the LD
> linker claims are "invalid" following a recovery event. I suspect a
> bug in the buffer cache since deleting the file still causes the old
> data to be returned from buffer cache even when the sectors are
> overwritten, but both are interrelated. Seems in some way related to
> EXT3 recovery which results in the buffer cache returning old sectors
> and junk.
>
> Not hard to reproduce, but the symptoms are always a little different
> but the /root/.viminfo file getting nuked seems a common affect of
> this bug.
"file system corruption" usually means corrupted metadata, but I guess
here you mean file corruption, i.e. corrupted data.
If you have buffered data in the cache, it will be lost when you pull
the plug. If your userspace doesn't sync it, this is expected. But it's
not clear to me what you're seeing.
I'm also not clear on what you mean about deleting the file and having old
data returned. Maybe a little cut and paste from the screen would help
explain what you see.
I'd also check CONFIG_EXT3_DEFAULTS_TO_ORDERED and be sure you're
using data=ordered mode by default.
-Eric
> Jeff
next prev parent reply other threads:[~2010-06-07 21:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 20:45 EXT3 File System Corruption 2.6.34 Jeffrey Merkey
2010-06-07 20:59 ` Eric Sandeen [this message]
[not found] ` <AANLkTik1T2nJxsoK9UGIVy6q6pfSxniFfJXJY0InmuUh@mail.gmail.com>
2010-06-07 23:55 ` Fwd: " Jeffrey Merkey
2010-06-08 1:10 ` Eric Sandeen
[not found] ` <AANLkTilrmEnLrxRSYNnwr8vFaZi7R9U5vY39NmBWUEMy@mail.gmail.com>
2010-06-08 1:55 ` Fwd: " Jeffrey Merkey
2010-06-08 2:05 ` Eric Sandeen
2010-06-10 21:04 ` Bill Davidsen
2010-06-11 16:23 ` Jeffrey Merkey
2010-06-08 1:57 ` Jeffrey Merkey
[not found] ` <C4177A0B-9A74-40E6-9A58-64418034232C@sandeen.net>
[not found] ` <AANLkTinzZkN9agekI5eqzA9hERsghI7yDJyAy1O755dr@mail.gmail.com>
2010-06-08 2:14 ` Jeffrey Merkey
2010-06-08 11:14 ` Theodore Tso
2010-06-08 13:33 ` Török Edwin
2010-06-09 0:49 ` david
[not found] ` <4C0DA955.7020802@sandeen.net>
2010-06-08 2:37 ` Jeffrey Merkey
2010-06-08 5:40 ` Valdis.Kletnieks
2010-06-08 14:44 ` Jeffrey Merkey
2010-06-07 21:04 ` Valdis.Kletnieks
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=4C0D5DCD.5010201@sandeen.net \
--to=sandeen@sandeen.net \
--cc=jeffmerkey@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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