Date: Mon, 18 Mar 2002 11:03:34 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: John De Boskey <jwd@FreeBSD.org> Cc: Arch List <freebsd-arch@FreeBSD.org> Subject: Re: ftpd ESTALE recovery patch Message-ID: <Pine.NEB.3.96L.1020318104609.25992C-100000@fledge.watson.org> In-Reply-To: <20020317084153.A3942@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Mar 2002, John De Boskey wrote:
> In a busy cluster, a generated file being handed out by ftp is
> failing due to an ESTALE condition. The following patch fixes the
> problem. Failure to open the file is also logged when -l is specified
> twice (see ftpd(8)).
Generally speaking, ESTALE means the file you're trying to access no
longer exists (stale file handle). This occurs in NFS unlike local
filesystems due to last-close-removes semantics, as opposed to
remove-revokes-access semantics. This is a fatal error condition, not a
transient one--by definition, the file you get on a retry will be a
different file than the one you started accessing before. It may be that
the higher level stream abstractions experience ESTALE more often during
open than the lower level fd abstractions as they may generate more NFS
RPCs during the open phase, increasing the window for file deletion during
open. I would have thought that for large files, you'd be much more
likely to get them later, where ESTALE would mean you couldn't
consistently return the file contents through a retry, I'm a little
surprised you catch so many in open (a very small file?)
Reasonable work-arounds include:
(1) Copying the file to the client (guarantee that ESTALE can't happen
during the transfer itself)
(2) Preserve the file for a window on the server, by renaming using
rename() in the same directory/file system, so that ESTALE is less
likely if the transfer happens in an expected amount of time. NFS
file handles persist across server renames assuming they are on the
same file system. This accepts the reality of ESTALE but reduces the
cost of implementing the feature by constraining the change to the
server.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020318104609.25992C-100000>