lkml.org 
[lkml]   [2003]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
Oleg Drokin <green@linuxhacker.ru> wrote:
>
> Hello!
>
> Andrew Morton <akpm@osdl.org> wrote:
> >> Here are the results (output of dmesg) from booting a kernel with this
> >> patch:
> >> set_blocksize: size=4096
> >> buffer layer error at fs/buffer.c:431
> AM> hm, that didn't tell us much :(
> AM> Could you add Oleg's patch as well?
>
> Actually it will say that device's block size is 4096 (confirming
> last set_blocksize was at least partially succesful),

Assuming that the printk is for the correct filesystem, yes.

> but what
> it does not tell us is how those buffers have survived after blocksize
> was changed and all buffers were invalidated.

Well reiserfs shouldn't be doing this:

bh = sb_bread (s, offset / s->s_blocksize);
...
sb_set_blocksize (s, sb_blocksize(rs));
brelse (bh);

but still, truncate_inode_pages() should be removing all those pages
unconditionally.


> (These buffers are there because reiserfs first reads that offset (in bytes)
> with whatever current blocksize is, except they should have been invalidated of
> course).
> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> everything, truncate_inode_pages() should have done this.

yup.

> So probably this page means do_invalidate_page() ... -> try_to_free_buffers()
> have failed for whatever reason.

See the pinned buffer, above.

> We did not write there yet, so this is not PageWriteback case.
> But if the read is still going on, I guess we won't free the page/buffers?
> Or am I missing some wait_on_buffer()?
> But anyway that might explains buffers being still in page, but not such
> a page present in a mapping. (except if we have not pickup this page from a list
> of free pages not looking that it still have stale buffers)

Yes, the page should have been removed from the mapping.


Amos, could you add this as well?

25-akpm/mm/truncate.c | 8 ++++++++
1 files changed, 8 insertions(+)

diff -puN mm/truncate.c~truncate_inode_pages-check mm/truncate.c
--- 25/mm/truncate.c~truncate_inode_pages-check Wed Oct 29 14:13:43 2003
+++ 25-akpm/mm/truncate.c Wed Oct 29 14:15:06 2003
@@ -174,6 +174,14 @@ void truncate_inode_pages(struct address
}
pagevec_release(&pvec);
}
+
+ if (lstart == 0) {
+ WARN_ON(mapping->nrpages);
+ WARN_ON(!list_empty(&mapping->clean_pages));
+ WARN_ON(!list_empty(&mapping->dirty_pages));
+ WARN_ON(!list_empty(&mapping->locked_pages));
+ WARN_ON(!list_empty(&mapping->io_pages));
+ }
}

EXPORT_SYMBOL(truncate_inode_pages);
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.091 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site