Re: [CHECKER] inconsistent NFS stat cache (NFS on ext3, 2.6.11)
From: Daniel Jacobowitz
Date: Sun Mar 13 2005 - 19:55:28 EST
On Sun, Mar 13, 2005 at 07:50:09PM -0500, Trond Myklebust wrote:
> Sorry, but you should _never_ have gotten an ESTALE error if the file
> was not in use when you deleted the old copy of glibc. A fresh call to
> open() will always result in a new lookup of the filehandle.
> What may have happened in the case of the EIO error is that you may have
> raced: i.e. a client starts reading the file while it is being copied
It is in a separate root filesystem, currently not used by anything on
the target. It is likely to be in cache, but I can absolutely
guarantee it isn't open. Hmm, server is x86_64 2.6.7, client is 2.6.10
MIPS. I should upgrade them and see if that helps.
Unfortunately I haven't found any smaller testcases than installing an
entire root FS.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/