From owner-freebsd-hackers Tue Feb 23 18: 4:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id D833511390 for ; Tue, 23 Feb 1999 18:04:47 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA13468; Tue, 23 Feb 1999 19:25:52 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd013289; Tue Feb 23 19:25:41 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA26138; Tue, 23 Feb 1999 19:04:20 -0700 (MST) From: Terry Lambert Message-Id: <199902240204.TAA26138@usr09.primenet.com> Subject: Re: ESTALE the best approach? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 24 Feb 1999 02:04:20 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG In-Reply-To: <199902240115.RAA54511@apollo.backplane.com> from "Matthew Dillon" at Feb 23, 99 05:15:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The most common occurance of ESTALE that I know of is when a file is > deleted on an NFS server. This is the least common, by my reckoning, but YMMV; you were certainly running a different environment at Best. > This is an unrecoverable condition. That is, the open descriptor in > question should return ESTALE forever. You'd have to reopen the file > to fix it. It is not appropriate to automatically remount the file > in that situation. For example, if someone on the server reinstalls a > binary there is no way in hell a process already running that binary image > on a client can recover. It must seg-fault, die, and be restarted. The deletion must have occurred on the server. It it occurred on another client, then it would be moved to a "." file until the last close. The correct client interlock is to lock the file, which of course it can not do in FreeBSD, without patches. The most common case I saw (in an environment where locking actually worked, as did NFSv3 LEASEs) was a server reboot rotating the numbers out from under the client, and the client failing a restart. In any case, if the ESTALE gets propagated to user space, rightly or wrongly, then the program must examine the return from "read" and take appropriate action (up to and including croaking). As a point of reference, I believe ESTALE to be intended as a purely kernel error. It is the lack of references to struct file *'s that reference a particular vnode (that may reference an NFSnode) that preclude invalidating the open file instances, resulting in the correct error to user space, which is EBADF. An interesting causal effect of this lack of reference backpointer is the need to support deadfs as a placeholder on vnode revocation (this is, in fact, a kludge to "repair" the kludge of no reference backpointer). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message