Date: Tue, 23 Feb 1999 17:15:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: toasty@home.dragondata.com (Kevin Day), hackers@FreeBSD.ORG Subject: Re: ESTALE the best approach? Message-ID: <199902240115.RAA54511@apollo.backplane.com> References: <199902240055.RAA22403@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400)
:> 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle
:
:Whatever is calling this is not checking the return value for read.
:...
:Yes. The main problem is that the ESTALE does not trigger a remount
:attempt, like it should, and a subsequent cleanup of the mount specific
:portions of the outstanding NFSnodes.
:
:Generally, the remount attempt is signalled by statd.
:
:The ESTALE is actually a result of the mount going south, and not
:getting reset like it's supposed to be. In theory, it should never
:make user space, unless the remount attempts are time or attempt-count
:constrained by mount options.
:
:The only way you get a stale node is a server reboot, and that's as a
:result of the "security" cruft that was nont implemented link-layer
:like it should have been (packet sequence randomization, etc.).
The most common occurance of ESTALE that I know of is when a file is
deleted on an NFS server.
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Basically, an operation was attempted against the server with an
:NFS mount that was invalid because the server reset the sequence
:base out from under you.
:
:NFS security was never intended to use weak techniques against session
:replay of plaintext; instead, it was intended to use DES or Kerberos,
:and not protect against replay at all (who care if you replay garbage?).
:
:
: Terry Lambert
: terry@lambert.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902240115.RAA54511>