freebsd stable - Mar 2018 - RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote:
[stuff snipped]
>In the source I saw nfs_async = 0; is it right that NFS will work in async
mode if I >compile the kernel with nfs_async = 1?
>
>I know the risk of running it async, but is it not the same risk having the
datastore >connected via iSCSI which standard is also not sync?
If you want to use it, you can just set it by setting the sysctl
vfs.nfsd.async=1.
- If the server crashes/reboots you can lose data. Also, after the reboot, the
  client will only see an temporarily unresponsive server and will not have any
  indication of data loss.
  (I am not familiar with iSCSI, so I can't comment on how safe that is.)
- If you are using ZFS, there is also a ZFS config (sync=disabled). I'm not
a ZFS
  guy, so I don't know anything more, but I'm sure others reading this
list can
  tell you how to set it.
[more stuff snipped]
>So far I did not see any issue with the mount. Only in the vmkernel.log
there are >often following entrees:
>WARNING: NFS41: NFS41ValidateDelegation:608: Server returned improper
>reason for no delegation: 2
The attached patch *might* get rid of these, although I don't think it
matters
much, since it is just complaining about the "reason" the server
returns for
not issuing a delegation (issuing delegations is entirely at the discretion of
the server and is disabled by default).
[more stuff snipped]
Good luck with it, rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wantdeleg.patch
Type: application/octet-stream
Size: 2114 bytes
Desc: wantdeleg.patch
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180305/9bbe6a78/attachment.obj>

Thanks, I am actually compiling with both patches.

I try now to get NFS 4.1 multipathing working. So I have now two connection on
different subnets between the ESXi host and the FreeBSD host with exports for
the same mountpoint on both subnets.
Now I get the following errors in the vmkernel.log:
2018-03-05T13:06:07.488Z cpu10:66503)WARNING: NFS41: NFS41_Bug:2361: BUG -
Invalid BIND_CONN_TO_SESSION error: NFS4ERR_NOTSUPP

Is there session trunking available in the FreeBSD NFS41 implementation?

Br,
andi

-----Original Message-----
From: Rick Macklem [mailto:rmacklem at uoguelph.ca] 
Sent: Montag, 5. M?rz 2018 02:16
To: NAGY Andreas <Andreas.Nagy at frequentis.com>; 'freebsd-stable at
freebsd.org' <freebsd-stable at freebsd.org>
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS?failed error in combination with ESXi
client

NAGY Andreas wrote:
[stuff snipped]
>In the source I saw nfs_async = 0; is it right that NFS will work in async
mode if I >compile the kernel with nfs_async = 1?
>
>I know the risk of running it async, but is it not the same risk having the
datastore >connected via iSCSI which standard is also not sync?
If you want to use it, you can just set it by setting the sysctl
vfs.nfsd.async=1.
- If the server crashes/reboots you can lose data. Also, after the reboot, the
  client will only see an temporarily unresponsive server and will not have any
  indication of data loss.
  (I am not familiar with iSCSI, so I can't comment on how safe that is.)
- If you are using ZFS, there is also a ZFS config (sync=disabled). I'm not
a ZFS
  guy, so I don't know anything more, but I'm sure others reading this
list can
  tell you how to set it.
[more stuff snipped]
>So far I did not see any issue with the mount. Only in the vmkernel.log
there are >often following entrees:
>WARNING: NFS41: NFS41ValidateDelegation:608: Server returned improper 
>>reason for no delegation: 2
The attached patch *might* get rid of these, although I don't think it
matters much, since it is just complaining about the "reason" the
server returns for not issuing a delegation (issuing delegations is entirely at
the discretion of the server and is disabled by default).
[more stuff snipped]
Good luck with it, rick