Jeff Mahoney <jeffm@xxxxxxxx> wrote: > > In my experience, the loop is actually outside of > __find_get_block_slow(), in __getblk_slow(). I've been using xmon to > interrupt the kernel, and the results vary but are all rooted in the > for(;;) loop in __getblk_slow. It appears as though grow_buffers is > finding/creating the page, but then __find_get_block can't locate the > buffer it needs. Yes, that'll happen. Because there are still buffers attached to the page which have the wrong blocksize. Say, if someone is trying to read a 2k buffer_head which is backed by a page which already has 1k buffer_heads attached to it. Does your kernel not have that big printk in __find_get_block_slow()? If it does, maybe some of the buffers are unmapped. Try: --- 25/fs/buffer.c~a Tue Feb 22 15:27:35 2005 +++ 25-akpm/fs/buffer.c Tue Feb 22 15:27:41 2005 @@ -456,7 +456,7 @@ __find_get_block_slow(struct block_devic * file io on the block device and getblk. It gets dealt with * elsewhere, don't buffer_error if we had some unmapped buffers */ - if (all_mapped) { + { printk("__find_get_block_slow() failed. " "block=%llu, b_blocknr=%llu\n", (unsigned long long)block, (unsigned long long)bh->b_blocknr); _