On Mon, Mar 04, 2013 at 08:32:45AM +, Tony Lu wrote:
> Thanks for you following up.
>
> My apologize that I just found that it is one change I made before
> that causes this problem. This change forces mkfs.xfs to format
> xfs partitions whose sectorsize were not smaller than 4096 bytes,
> whi
t;-Original Message-
>From: Mark Tinguely [mailto:tingu...@sgi.com]
>Sent: Saturday, March 02, 2013 4:24 AM
>To: Tony Lu
>Cc: Alex Elder; linux-kernel@vger.kernel.org; Chris Metcalf; x...@oss.sgi.com;
>Ben Myers; Dave Chinner; linux-fsde...@vger.kernel.org
>Subjec
On 03/01/13 09:51, Mark Tinguely wrote:
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 re
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
moun
On Tue, Feb 26, 2013 at 07:28:19AM +, 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 filesys
On Sun, Feb 24, 2013 at 04:46:30AM +, Tony Lu wrote:
> >> For example, if xlog_bread_noalign() wants to read blocks from #1
> >> to # 9, in which case the passed parameter blk_no is 1, and nbblks
> >> is 8, sectBBsize is 8, after the round down and round up
> >> operations, we get blk_no as 0,
>> For example, if xlog_bread_noalign() wants to read blocks from #1
>> to # 9, in which case the passed parameter blk_no is 1, and nbblks
>> is 8, sectBBsize is 8, after the round down and round up
>> operations, we get blk_no as 0, and nbblks as still 8. We
>> definitely lose the last block of th
On Sat, Feb 23, 2013 at 07:06:10AM +, Tony Lu wrote:
> >From: Dave Chinner [mailto:da...@fromorbit.com]
> >On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
> >> I encountered the following panic when using xfs partitions as rootfs,
> >> which
> >> is due to the truncated log data read
>-Original Message-
>From: Ben Myers [mailto:b...@sgi.com]
>
>Hi Tony,
>
>On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
>> I encountered the following panic when using xfs partitions as rootfs, which
>> is due to the truncated log data read by xlog_bread_noalign(). We should
>> e
>From: Dave Chinner [mailto:da...@fromorbit.com]
>On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
>> I encountered the following panic when using xfs partitions as rootfs, which
>> is due to the truncated log data read by xlog_bread_noalign(). We should
>> extend the buffer by one extra lo
On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
> I encountered the following panic when using xfs partitions as rootfs, which
> is due to the truncated log data read by xlog_bread_noalign(). We should
> extend the buffer by one extra log sector to ensure there's enough space to
> accommod
Hi Tony,
On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
> I encountered the following panic when using xfs partitions as rootfs, which
> is due to the truncated log data read by xlog_bread_noalign(). We should
> extend the buffer by one extra log sector to ensure there's enough space to
I encountered the following panic when using xfs partitions as rootfs, which
is due to the truncated log data read by xlog_bread_noalign(). We should
extend the buffer by one extra log sector to ensure there's enough space to
accommodate requested log data, which we indeed did in xlog_get_bp(), but
13 matches
Mail list logo
