Re: Checking page_count(page) in invalidate_complete_page

Nick Piggin
2006-09-27T04:47:26Z

Chuck Lever wrote:

> Nick Piggin wrote:
>
>> So that raises another question: how do they get to
>> invalidate_inode_pages2
>> if they are not part of the buffer or pagecache?
>
>
> It does use the page cache to cache data pages for files, directories,
> and symlinks. It does not use buffers, however, since incoming file
> system data is read from a socket, not from a block device. I believe
> the client provides a dummy backing device for the few things in the
> VFS that require it.

OK, it uses the directory's inode's pagecache rather than the block's
buffer cache like AFAIK many other
filesystems do. That's OK, I like that model better anyway ;)

> Invalidate_inode_pages2() is used to remove page cache data that the
> client has determined is stale. The client detects that the file has
> changed on the server, and it is not responsible for those changes, by
> examining the file's attributes and noticing mtime or size changes.
> When such a change is detected, all pages cached for a file are
> invalidated, and the page cache is gradually repopulated from the
> server as applications access parts of the file.
>
> I'd like to understand the difference between
> invalidate_inode_pages2() and truncate_inode_pages() in this scenario.

truncate_inode_pages will a) throw away everything including dirty
pages, and b) probably be fairly
racy unless the inode's i_size (for normal files) is modified.

We really want to make an invalidation that works properly for you.

If you can guarantee that a pagecache page can never get mapped to a
user mapping (eg. perhaps for
directories and symlinks) and also ensure that you don't dirty it via
the filesystem, then you don't
have to worry about it becoming dirty, so we can skip the checks Andrew
has added and maybe add a
WARN_ON(PageDirty()).

Now that won't help you for regular file pages that can be mmapped. For
those, we need to ensure
that the page isn't mapped, and the page will not be dirtied via a
get_user_pages user, and you need
to ensure that it can't get dirtied via the filesystem. The former two
will require VM changes of
the scale that aren't going to get into 2.6.19, but I'm working on them.

For now, can make do with flushing lru pagevecs, and also testing and
retrying in the caller?

--

Send instant messages to your online friends http://au.messenger.yahoo.com