Messages in this thread | | | Date | Fri, 10 Oct 2003 14:09:18 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
On Fri, 10 Oct 2003, Trond Myklebust wrote: > > In fact, I recently noticed that we still have this race in the NFS > file locking code: readahead may have been scheduled before we > actually set the file lock on the server, and may thus fill the page > cache with stale data.
The current "invalidate_inode_pages()" is _not_ equivalent to a specific user saying "these pages are bad and have to be updated".
The main difference is that invalidate_inode_pages() really cannot assume that the pages are bad: the pages may be mapped into another process that is actively writing to them, so the regular "invalidate_inode_pages()" literally must not force a re-read - that would throw out real information.
So "invalidate_inode_pages()" really is a hint, not a forced eviction.
A forced eviction can be done only by a user that says "I have write permission to this file, and I will now say that these pages _have_ to be thrown away, whether dirty or not".
And that's totally different, and will require a totally different approach.
(As to the read-ahead issue: there's nothing saying that you can't wait for the pages if they aren't up-to-date, and really synchronize with read-ahead. But that will require filesystem help, if only to be able to recognize that there is active IO going on. So NFS would have to keep track of a "read list" the same way it does for writeback pages).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |