From: Dave Chinner <david@fromorbit.com>
To: Tony Lu <zlu@tilera.com>
Cc: Ben Myers <bpm@sgi.com>, "xfs@oss.sgi.com" <xfs@oss.sgi.com>,
Alex Elder <elder@kernel.org>, Dave Chinner <dchinner@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Metcalf <cmetcalf@tilera.com>
Subject: Re: [PATCH] xfs: Fix possible truncation of log data in xlog_bread_noalign()
Date: Wed, 27 Feb 2013 07:52:41 +1100 [thread overview]
Message-ID: <20130226205241.GT5551@dastard> (raw)
In-Reply-To: <BAB94DBB0E89D8409949BC28AC95914C47C49005@USMAExch1.tad.internal.tilera.com>
On Tue, Feb 26, 2013 at 07:28:19AM +0000, Tony Lu wrote:
> I get a reliable way to reproduce this bug. The logprint and metadump are attached.
>
> Kernel version: 2.6.38.8
This is important....
....
.... because this:
> 4 umount /dev/sda1 /mnt
> 5 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> Starting XFS recovery on filesystem: sda1 (logdev: internal)
> Ending XFS recovery on filesystem: sda1 (logdev: internal)
Indicates that the unmount record is either not being written, it is
being written when there log has not been fully flushed or log
recovery is not finding it. You need to copy out the log
first to determine what the state of the log is before you mount the
filesystem - that way if log recovery is run you can see whether it
was supposed to run. (i.e. a clean log should never run recovery,
and unmount should always leave a clean log).
Either way, I'm more than 10,000 iterations into a run of 100k
iterations of this script on 3.8.0, and I have not seen a single log
recovery attempt occur. That implies you are seeing a bug in 2.6.38
that has since been fixed. It would be a good idea for you to
upgrade the system to a 3.8 kernel and determine if you can still
reproduce the problem on your system - that way we'll know if the
bug really has been fixed or not....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2013-02-26 20:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 8:12 [PATCH] xfs: Fix possible truncation of log data in xlog_bread_noalign() Tony Lu
2013-02-22 19:14 ` Ben Myers
2013-02-23 8:32 ` Tony Lu
2013-02-23 0:08 ` Dave Chinner
2013-02-23 7:06 ` Tony Lu
2013-02-23 23:55 ` Dave Chinner
2013-02-24 4:46 ` Tony Lu
2013-02-24 14:10 ` Dave Chinner
2013-02-26 7:28 ` Tony Lu
2013-02-26 20:52 ` Dave Chinner [this message]
2013-03-01 15:51 ` Mark Tinguely
2013-03-01 20:24 ` Mark Tinguely
2013-03-04 8:32 ` Tony Lu
2013-03-04 21:03 ` Dave Chinner
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=20130226205241.GT5551@dastard \
--to=david@fromorbit.com \
--cc=bpm@sgi.com \
--cc=cmetcalf@tilera.com \
--cc=dchinner@redhat.com \
--cc=elder@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
--cc=zlu@tilera.com \
/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).