[lkml]   [1996]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS still has caching problem

On Wed, 10 Jul 1996, Kees Bakker wrote:
> Today I have booted my system with linux-2.0.4, and saw it still has the
> following problem with directory caching. Let's first briefly describe the
> test environment.
> NFS server, called napoli, is an Alpha, and runs OSF1 v2.0
> NFS client 1, called lahti, runs linux-2.0.4 ('out of the box')
> NFS client 2, called pori, runs linux-1.3.83 (with my nfs/dir.c patch)
> The test is as follows:
> - on one client, write a file
> - then do a 'rsh' to another client and 'cat' the file
> - again, on the first client, write the same file, different contents
> - again, do a 'rsh' to another client and 'cat' the file
> You will see that the Linux clients keep showing the old contents if the
> size of the file remains the same. If the new size is different, then the
> Linux client shows the new contents.

This is NOT a bug - it's a feature. The problem is that NFS simply cannot
guarantee cache coherency, so either you have to disable caching
altogether, or you accept the fact that NFS has these surprising features.

The reason that Linux _does_ seem to work if the size has changed is that
there is a simple and stupid check that tries to avoid _most_ cases with
old caches. It simply notices that "uhhuh, the server has another size
than the one we've cached - better invalidate our cache".

There is also a timeout for the cache (default 30 seconds, if I remember
correctly, and you can set it by hand with a mount parameter), so the
update _will_ be seen eventually, but 30 seconds can be a longish time.

Now, I'm not saying that this is good behaviour, but on the whole it's a lot
better than not caching. I'd be happy to try to make the heuristic for cache
invalidates a bit better - one suggestion has been to make the timeout
shorter if the file has been modified recently (dynamic timeouts: if the
file hasn't been modified in the last month we use long timeouts, if it
has changed within the last few minutes we use a timeout of just a second
ot something like that).

So instead of the patch you sent (which looks fine, but it's a bit more
brute-force than I'd like), maybe you could look into the file "file.c"
and the "revalidate_inode()" function?


 \ /
  Last update: 2005-03-22 13:38    [W:0.175 / U:2.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site