Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > On Apr 21, 2022, at 7:52 PM, Rick Macklem <rmacklem@xxxxxxxxxxx> wrote: [stuff snipped] > > 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? Good question. For a UFS exported file system I am pretty sure the server would reply with ESTALE to the PutFH, just like Linux. For ZFS, I am not so sure. The translation from FH to vnode is done by a file system specific method. If that fails, ESTALE is replied. If ZFS can still generate a vnode for a file when it has been removed (or while the remove is in progress, as it might be in this case), then no error would be replied. (The NFSv4 Close operation doesn't actually use the vnode, it only uses the StateID and FH to find/close the NFSv4 open state.) The FreeBSD server never sets OPEN_RESULT_PRESERVE_UNLINKED in the Open reply and it is not intended to retain the file until Close. Maybe Andreas will find that out, if he can do more testing against a FreeBSD server? I am also not sure if the ESTALE replies are an issue for the ESXi client, since they happen multiple times in the packet trace and only generate a warning message in the client's log. I did not see anything else in the trace that would indicate why the client might be failing, however it did look like some packets were missing from the trace. rick -- Chuck Lever
