Re: NFS still has caching problem
Scott Street (scotts@monster.doa.net)
Thu, 11 Jul 1996 22:23:07 -0400 (EDT)
> > 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".
Linus,
Why did this check fail anyway? If (I'm looking at 2.0.0 src) linux
checks the last modified date and the size (from what I can tell in
file.c revalidate_inode(), why didn't the cache update? The date
should have changed for the "new" copy of the file.
Of course the silly answer is the date didn't change, but then isn't that
a "feature" of the NFS server?
Or are we looking at the wrong time/date value, like the created date
as opposed to the last modified date?
BTW: this does happen between two linux 2.0 boxes.