ESTALE after cwd deleted by same NFS client

[Rick Macklem]

Benjamin Kaduk wrote:

>On Mon, Dec 12, 2016 at 06:15:14AM +0000, Colin Percival wrote:
>> On 12/11/16 21:42, Benjamin Kaduk wrote:
>> > On Sun, Dec 11, 2016 at 11:06:42PM +0000, Colin Percival wrote:
>> >> If I run the following with /nfs/ being an NFS mount:
>> >> # mkdir /nfs/foo
>> >> # touch /nfs/foo/bar
>> >> # cd /nfs/foo
>> >> # rm -r /nfs/foo
>> >> # rm bar
If this is happening on a single client, something is broken.
- For this step, the name cache should have a miss and the Lookup should fail with
  ENOENT. I think the most likely failures are...
  --> Either the name cache in the client is broken and has a hit
  OR
  --> The server replies NFS_OK for the lookup, even though it should have been removed.

When I get home on the weekend, I'll try this against a FreeBSD and Linux server, to see
if it fails. If it does, then I'll try to figure out why.
(Version of NFS shouldn't matter for this case. They recently added the optional case
 of a server that can retain files after an NFSv4 Remove until the NFSv4 Close, making
 it more POSIX like. I think that's NFSv4.2, but it might be in NFSV4.1.)

Did you try:
sysctl debug.disable_vnfullpath=1 (or something close to disable_vnfullpath)
to see if it helped?

rick

>> >>
>> >> Then the final 'rm bar' fails with 'Stale NFS file handle'.
>> >
>> > Amusingly, this just came up recently:
>> >
>> > https://www.ietf.org/mail-archive/web/nfsv4/current/msg15115.html (et seq)
>> >
>> > But I guess you did not specify which version of the NFS protocol you were
>> > using...
>>
>> I'm using NFSv4.1, but this isn't quite the same... that link refers to having
>> one NFS client remove a file out from underneath a different client, while I'm
>> talking about having an NFS client remove a file from underneath *itself*.
>
>I thought the reply mentioned (in passing) the case of a client removing a
>file out from under itself as well.  But, maybe I was reading too fast.
>
>-Ben