Subject: Re: Cache invalidation bug in NFS v3 - trivially reproducible
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Leif Nixon <nixon@nsc.liu.se>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <m33bn8bet4.fsf@nammatj.nsc.liu.se>
References: <m33bn8bet4.fsf@nammatj.nsc.liu.se>
Content-Type: text/plain
Date: Tue, 11 Oct 2005 10:47:57 -0400
Message-Id: <1129042077.11164.9.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1188
Lines: 36

ty den 11.10.2005 Klokka 11:09 (+0200) skreiv Leif Nixon:
> Hi,
> 
> We have come across a bug where a NFS v3 client fails to invalidate
> its data cache for a file even though it realizes that the file
> attributes have changed. We have been able to recreate the bug on a
> range of kernel versions and different underlying file systems.
> 
> Here's a minimal way to reproduce the error (there seems to be some
> timing issues involved, but this has worked at least 90% of the time):
> 
>   NFS client n1                NFS client n2
> 
>   $ echo 1 > f
> 			       $ cat f
> 			       1
>   $ touch .
>   $ echo 2 > f
> 			       $ touch f
> 			       $ cat f
> 			       1
> 
> Now client n2 is stuck in a state where it uses its old cached data
> forever (or at least for several hours):

Yep. I can see a problem whereby the cache is "losing" consistency
information when you do this sort of thing. I'm working on a fix.

Cheers,
  Trond

-
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/