> On Apr 21, 2022, at 7:52 PM, Rick Macklem <rmacklem@xxxxxxxxxxx> wrote: > > J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > [stuff snipped] >> On Thu, Apr 21, 2022 at 12:40:49PM -0400, bfields wrote: >>> >>> >>> Stale filehandles aren't normal, and suggest some bug or >>> misconfiguration on the server side, either in NFS or the exported >>> filesystem. >> >> Actually, I should take that back: if one client removes files while a >> second client is using them, it'd be normal for applications on that >> second client to see ESTALE. > I took a look at crispyduck's packet trace and here's what I saw: > Packet# > 48 Lookup of test-ovf.vmx > 49 NFS_OK FH is 0x7c9ce14b (the hash) > ... > 51 Open Claim_FH fo 0x7c9ce14b > 52 NFS_OK Open Stateid 0x35be > ... > 138 Rename test-ovf.vmx~ to test-ovf.vmx > 139 NFS_OK > ... > 141 Close with PutFH 0x7c9ce14b > 142 NFS4ERR_STALE for the PutFH > > So, it seems that the Rename will delete the file (names another file to the > same name "test-ovf.vmx". Then the subsequent Close's PutFH fails, > because the file for the FH has been deleted. So, Rick, Andreas: does this sequence of operations work without error against a FreeBSD NFS server? -- Chuck Lever
