From: Mark Tinguely <tinguely@sgi.com>
To: Tony Lu <zlu@tilera.com>
Cc: Alex Elder <elder@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Metcalf <cmetcalf@tilera.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>, Ben Myers <bpm@sgi.com>,
Dave Chinner <dchinner@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] xfs: Fix possible truncation of log data in xlog_bread_noalign()
Date: Fri, 01 Mar 2013 09:51:58 -0600 [thread overview]
Message-ID: <5130CE9E.9080501@sgi.com> (raw)
In-Reply-To: <BAB94DBB0E89D8409949BC28AC95914C47C49005@USMAExch1.tad.internal.tilera.com>
On 02/26/13 01:28, Tony Lu wrote:
> I get a reliable way to reproduce this bug. The logprint and metadump are attached.
>
> Kernel version: 2.6.38.8
> Mkfs.xfs version: xfsprogs-3.1.1
> mkfs.xfs -s size=4096 /dev/sda1
>
> Run the following mount-cp-umount script to reproduce:
> #!/bin/sh
> device=/dev/sda1
> mount_point=/mnt
> times=10
>
> for ((num=1;num<=$times;num++))
> do
> echo "$num mount $device $mount_point"
> mount $device $mount_point
>
> echo "cp -rf /bin $mount_point/$num"
> cp -rf /bin $mount_point/$num
>
> echo "$num umount $device $mount_point"
> umount $mount_point
>
> #num=$(($num + 1))
> done
>
> After several times of mount/cp/umount, this xfs crashes, and the xfs partition can not be mounted any more. Here is the output of console.
> -sh-4.1# ./umount-test
> 1 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> cp -rf /bin /mnt/1
> 1 umount /dev/sda1 /mnt
> 2 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> cp -rf /bin /mnt/2
> 2 umount /dev/sda1 /mnt
> 3 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> cp -rf /bin /mnt/3
> 3 umount /dev/sda1 /mnt
> 4 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> cp -rf /bin /mnt/4
> 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)cp -rf /bin /mnt/5
> 5 umount /dev/sda1 /mnt
> 6 mount /dev/sda1 /mnt
>
> XFS mounting filesystem sda1
> Starting XFS recovery on filesystem: sda1 (logdev: internal)
> Ending XFS recovery on filesystem: sda1 (logdev: internal)Interrupt
> cp -rf /bin /mnt/6
> 6 umount /dev/sda1 /mnt
> 7 mount /dev/sda1 /mnt
>
> XFS mounting filesystem sda1
> cp -rf /bin /mnt/7
> 7 umount /dev/sda1 /mnt
> Interrupt
> 8 mount /dev/sda1 /mnt
> XFS mounting filesystem sda1
> Starting XFS recovery on filesystem: sda1 (logdev: internal)
> XFS: xlog_recover_process_data: bad clientid
> XFS: log mount/recovery failed: error 5
> XFS: log mount failed
>
> Thanks
> -Tony
It works fine on a 2.6.32 machine I had sitting around - and I never
required log recovery.
I think you need to answer Dave's question as to why is your unmounts
are requiring recovery?
Are there errors in the /var/log/messages?
I downloaded the Linux 2.6.38.8 source and take a look if I can recreate
the problem.
--Mark.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-01 15:51 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
2013-03-01 15:51 ` Mark Tinguely [this message]
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=5130CE9E.9080501@sgi.com \
--to=tinguely@sgi.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).