Messages in this thread | | | Subject | RE: nfs client readdir caching issue? | Date | Thu, 3 Jul 2008 09:47:06 +0100 | From | "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
| |