On 20 Oct 2000, Trond Myklebust wrote:
>
> The problem here is that NFS pages have 3 rather than 2 states:
> 1) mmapped & correct.
> 2) mmapped & incorrect. (but possibly dirty)
> 3) Unmapped
>
> For case 1), we clearly want to have the page in inode->i_mapping.
> For cases 2) & 3) we don't.
I think you're WRONG, WRONG, WRONG.
Your case #2 is not at all a state.
It's "mapped, possibly dirty, and locally correct. But _maybe_ globally
incorrect".
If you remove the page in case #2 from the hashing, you will have case #4,
which you're ignoring:
4) Totally, and utterly incorrect. Without any way for the application
to even _know_ that it's incorrect.
Note that case 4 is accompanied by case #5, later on:
5) two separate pages both mapped, one hashed and up-to-date, the other
mapped in other processes but incorrect.
which is really really bad, because now you have the case that you have
'n' copies of the same page in memory, with 'n' users, out of which 'n-1'
users have the wrong page. And those 'n-1' users don't even have any way
of _knowing_ that they have the wrong page.
Which is why we MUST NOT drop a page that has users. Really.
I'm telling you that cases #4 and #5 are _much_ worse than your "solution"
to case #2. And you argue that your solution is good only because you're
completely ignoring cases #4 and #5.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:17 EST