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

Okay, that was the main reason for using NFS 4.1.
Is it planned to implement it, or is the focus on pNFS?

Thanks,
Andi


________________________________
Von: Rick Macklem <rmacklem at uoguelph.ca>
Gesendet: 05.03.2018 11:49 nachm.
An: NAGY Andreas; 'freebsd-stable at freebsd.org'
Betreff: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client

Nope, that isn't supported, rick
(Hope no one is too upset by a top post.)

________________________________________
From: NAGY Andreas <Andreas.Nagy at frequentis.com>
Sent: Monday, March 5, 2018 8:22:10 AM
To: Rick Macklem; 'freebsd-stable at freebsd.org'
Subject: RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client

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

NAGY Andreas wrote:
>Okay, that was the main reason for using NFS 4.1.
>Is it planned to implement it, or is the focus on pNFS?
Do the VMware people claim that this improves performance?
(I know nothing about the world of VMs, but for real hardware
 I can't see any advantage of having more than one TCP connection?
 As far as I know, the Linux client never tries to acquire a second TCP
 connection. I would have assumed trunking would be handled below
 TCP.)

This is the first client that I am aware of (and just yesterday when you pointed
it out) that uses BIND_CONN_TO_SESSION for an additional TCP connection.
(Up until now I was only aware of it being used for RDMA setups and I have no
 hardware to play with such things.)

If the VMware folk claim it does improve performance, I might get around to
it someday, although you are correct that I am working on pNFS support for the
server right now.

rick
[stuff snipped]

NAGY Andreas wrote:
>Okay, that was the main reason for using NFS 4.1.
>Is it planned to implement it, or is the focus on pNFS?
I took a quick look and implementing this for some cases will be pretty
easy. Binding a FORE channel is implied, so for that case all the server
does is reply OK to the BIND_CONN_TO_SESSION.

To know if the ESXi client case is a simple one, I need to see what the
BIND_CONN_TO_SESSION arguments look like.
If you can capture packets for when this second connection is done and
email it to me as an attachment, I can look at what the BIND_CONN_TO_SESSION
args are.
# tcpdump -s 0 -w <file.pcap> host <client-host-for-this-connection>
run on the FreeBSD server should get the <file.pcap> I need.

Alternately, if you have wireshark handy, you can just use it to look
for the BIND_CONN_TO_SESSION request and see if it specifies
(FORE, BACK, FORE_OR_BOTH or BACK_OR_BOTH) in it.
FORE or FORE_OR_BOTH means it is easy to do and I can probably have
a patch for testing in a day or two.

rick