Date: Fri, 20 Jun 2003 11:05:28 +0400 (MSD) From: Andrey Alekseyev <uitm@blackflag.ru> To: tlambert2@mindspring.com (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: open() and ESTALE error Message-ID: <200306200705.LAA00432@slt.oz> In-Reply-To: <3EF29A62.5E91D714@mindspring.com> from Terry Lambert at "Jun 19, 3 10:23:46 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry, Thanks much for you comments, but see below. > The real problem here is that you know you did an operation > on the file which would break the name/nfsnode relationship, > but did not flush the cached name and nfsnode data. nfs_request() actually calls cache_purge() on ESTALE, and vn_open() frees vnode with vput() if a lookup was successful but there were an error from the underlying filesystem (like ESTALE resulting from nfs_request() which is eventually called from VOP_ACCESS or VOP_OPEN). > A more correct solution would resync the nfsnode. I think this is exactly what happens :) Actually, I believe, I'm just getting another namecache entry with another vnode/nfsnode/file handle. > The main problem with your solution is that it doesn't work > in the case that you don't know the name of the remote file > (in which case, all you really have is a stale file handle, > with no way to unstale it). I think, in this case (if the file was rm'd on the server), I'll just get ENOENT from the second vn_open() attempt, which would be more than appropriate. A real drawback is that for a stale "current" directory it'll take another lookup to detect "true" ESTALE. > This would fix a lot more cases than the single failure you > are fixing. Actually, as I said, I played with different parts of the code to solve this (including, nfs_open(), nfs_access(), nfs_lookup() and vn_open()) only to find the previously mentioned solution to be the simpliest and most suitable for all situations (for me!) :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306200705.LAA00432>