[lkml]   [2008]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: nfs client readdir caching issue?
    > If so, then invalidate_inode_pages2_range() would have to be broken:
    > 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)

    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,

    IE purge the rest of the pages for the inode.

    Andy, BlueArc Engineering

     \ /
      Last update: 2008-07-03 14:55    [W:0.022 / U:58.492 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site