> It looks like you might need: for (i--; i >= 0; i--)
> (or: for (j = 0; j < i; j++) etc.)
>
> Because if the initial alloc_page loop goes to completion then:
> i == pagecount
> and if alloc_page loop terminates early then
> bp->b_pages[i] == NULL
> So we have gone 1 too far in both cases and n
Hi,
--On 9 March 2007 12:55:11 PM +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
Ed Cashin found a bug in the error handling code for the case where
a page allocation fails. Here's the updated version:
Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===
Ed Cashin found a bug in the error handling code for the case where
a page allocation fails. Here's the updated version:
Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c 2007-03-08 19:08
Incore log buffers are not always a power of two of the page size.
In particular, when xfs is running over software raid devices, the
log buffers are allocated to match the size of a stripe.
However, they are always a multiple of PAGE_SIZE, so we are still safe.
Michael
Christoph Hellwig wrot
On Wed, Mar 07, 2007 at 09:04:53AM -0800, Michael Nishimoto wrote:
> Incore log buffers are not always a power of two of the page size.
> In particular, when xfs is running over software raid devices, the
> log buffers are allocated to match the size of a stripe.
>
> However, they are always a mul
On Wed, Mar 07, 2007 at 05:44:24PM +0530, Shailendra Tripathi wrote:
> Hi Christoph,
>Did you do some testing for recovery when end of the physical
>log is seen ?
I ran xfsqa over it, which should catch this case.
>When you will be dealing with striped ICLOG b
Hi Christoph,
Did you do some testing for recovery when end of the physical log
is seen ?
When you will be dealing with striped ICLOG buffers or big sized
ICLOGs, header size might range from 512 to 2k. Also, this header might
be split into 2 parts at the end of physical log. Then,
7 matches
Mail list logo
