From: Dave Chinner <david@fromorbit.com>
To: linux-ext4@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.35-r5 ext3 corruptions
Date: Tue, 20 Jul 2010 08:45:12 +1000 [thread overview]
Message-ID: <20100719224512.GD32635@dastard> (raw)
In-Reply-To: <20100715105745.GI30737@dastard>
On Thu, Jul 15, 2010 at 08:57:45PM +1000, Dave Chinner wrote:
> Upgrading my test vms from 2.6.35-rc3 to 2.6.35-rc5 is resulting in
> repeated errors on the root drive of a test VM:
>
> { 1532.368808] EXT3-fs error (device sda1): ext3_lookup: deleted inode referenced: 211043
> [ 1532.370859] Aborting journal on device sda1.
> [ 1532.376957] EXT3-fs (sda1):
> [ 1532.376976] EXT3-fs (sda1): error: ext3_journal_start_sb: Detected aborted journal
> [ 1532.376980] EXT3-fs (sda1): error: remounting filesystem read-only
> [ 1532.420361] error: remounting filesystem read-only
> [ 1532.621209] EXT3-fs error (device sda1): ext3_lookup: deleted inode referenced: 211043
>
> The filesysetm is a mess when checked on reboot - lots of illegal
> references to blocks, multiply linked blocks, etc, but repairs.
> Files are lots, truncated, etc, so there is visible filesystem
> damage.
>
> I did lots of testing on 2.6.35-rc3 and came across no problems;
> problems only seemed to start with 2.6.35-rc5, and I've reproduced
> the problem on a vanilla 2.6.35-rc4.
>
> The problem seems to occur randomly - sometimes during boot or when
> idle after boot, sometimes a while after boot. I haven't done any
> digging at all for the cause - all I've done so far is confirm that
> it is reproducable and it's not my code causing the problem.
Looks like this problem was isolated to a single VM and root
filesystem. I could not reproduce it on anything other than the
one filesystem that was failing.
Unfortunately, I had a fat-fingered moment and backed up the wrong
filesystem image at the outset. So after I smashed the original
filesystem into oblivion (one failure lead to half the filesystem in
lost+found), I had nothing to restore from to continue testing.
So I re-imaged the root filesystem and the problem has not occurred
despite trying for more than a day. When it was bad, it didn't take
more than a few minutes of activity to reproduce. Hence I can only
conclude there was something wrong with the filesystem itself that
wasn't being detected, not some more generic problem....
I'll go add this to the bugzilla and close it down.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-07-19 22:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-15 10:57 2.6.35-r5 ext3 corruptions Dave Chinner
2010-07-15 11:26 ` Dave Chinner
2010-07-15 18:23 ` Josef Bacik
2010-07-15 20:14 ` Johannes Hirte
2010-07-19 22:45 ` Dave Chinner [this message]
2010-07-21 6:32 ` Dave Chinner
2010-07-21 11:07 ` Török Edwin
2010-07-21 14:01 ` Eric Sandeen
2010-07-21 13:55 ` Eric Sandeen
2010-07-23 10:43 ` Jan Kara
2010-07-23 10:53 ` Jan Kara
2010-07-23 10:55 ` Dave Chinner
2010-07-23 10:58 ` Christoph Hellwig
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=20100719224512.GD32635@dastard \
--to=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).