RE: nfs client readdir caching issue?

[Andy Chittenden]

> If so, then invalidate_inode_pages2_range() would have to be broken:
we
> always clear the readdir cache immediately after reading in the page
> with index 0 (i.e. the first readdir page).

I'm confused by the call to invalidate_inode_pages2_range:

        if (page->index == 0)
                invalidate_inode_pages2_range(inode->i_mapping,
PAGE_CACHE_SIZE, -1);

That's passing in a pgoff_t of 4096 as the start page offset from which
to invalidate. And an enormous number for the end page to invalidate to.
So it looks like the nfs client is trying to invalidate from a *byte*
offset of 4096 (but if that's true, the first page could contain less
than 4096 bytes depending on the size of the readdir response it
received but I'll leave that to one side for the moment).

What's confusing me is that when I look at the implementation of
invalidate_inode_pages2_range, I see this call to pagevec_lookup:

                pagevec_lookup(&pvec, mapping, next,
                        min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1))
{

looking at the pagevec_lookup comments, it claims the fourth parameter
is the number of pages:

* @nr_pages:   The maximum number of pages

So how can (end - next) be a number of pages? (next will be 4096 in the
call from the nfs client). IE it looks like
invalidate_inode_pages2_range is expecting a page range (as the name
suggests). IE I'm wondering whether the call to
invalidate_inode_pages2_range should be:

        if (page->index == 0)
                invalidate_inode_pages2_range(inode->i_mapping, 1, -1);

FWIW We've also seen this on larger directories so I'm wondering what
would happen if a readdir part way down the cookie chain returned more
data (or less) than it did last time. IE if the above is correct, then
replace the two lines with:

	invalidate_inode_pages2_range(inode->i_mapping, page->index + 1,
-1);

IE purge the rest of the pages for the inode.

-- 
Andy, BlueArc Engineering

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