Messages in this thread | | | Date | Sun, 13 Mar 2005 19:54:13 -0500 | From | Daniel Jacobowitz <> | Subject | Re: [CHECKER] inconsistent NFS stat cache (NFS on ext3, 2.6.11) |
| |
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 > to.
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.
-- Daniel Jacobowitz CodeSourcery, LLC - 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/
| |