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,
>
ginal 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
>Subject: Re:
[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
Subject: Re: [PATCH] xfs: Fix possible truncation of log data in
xlog_bread_noalign()
On 03/01
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,
which
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
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
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
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
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
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 filesystem
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,
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, and nbblks
>> 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
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
>>
-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
extend the
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 by
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 the log
>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
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
>
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(),
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(),
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
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
accommodate
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 log
26 matches
Mail list logo