NAGY Andreas
2018-Mar-04 18:22 UTC
RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client
Okay, the slow write was not a NFS problem, it was the hw raid controller which switched to write through because of a broken battery. 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? The last weeks I tested the following setup: Two FreeBSD hosts with a more or less good hw RAID controller in a HAST cluster providing a datastore to two ESXi hosts via iSCSI. This setup worked quiet well, but I now want to switch to NFS, and hope to get equivalent speeds. Thanks so far, andi -----Original Message----- From: NAGY Andreas Sent: Sonntag, 4. M?rz 2018 14:26 To: Rick Macklem <rmacklem at uoguelph.ca>; freebsd-stable at freebsd.org Subject: RE: NFS 4.1 RECLAIM_COMPLETE FS?failed error in combination with ESXi client Thanks, got it working with your patch. 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 Actually I have only a single link between the ESXi host and the FreeBSD host, but as soon as I figure out what Is the right way to configure multiple paths for NFS I will do more testing. I need also to check out what can be tuned. I expected that writes to the NFS datastore will be slower than iSCSI but not as slow as it is now. andi -----Original Message----- From: Rick Macklem [mailto:rmacklem at uoguelph.ca] Sent: Sonntag, 4. M?rz 2018 06:48 To: NAGY Andreas <Andreas.Nagy at frequentis.com>; freebsd-stable at freebsd.org Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS?failed error in combination with ESXi client NAGY Andreas wrote:>Hi and thanks! > >First time using/needing a patch could you give me a short advise how to use it >and for which version?The only difference with kernel versions will be the line#s.>So far I have made a fresh FreeBSD 11.1 RELEASE install as a VM on a >ESXi host >updated the system and did a svn checkout >http://svn.freebsd.org/base/release/11.1.0/ > >Then tried to apply the patch in /usr/src/sys via patch < >/tmp/reclaimcom2.patch > >Output was: >Hmm... Looks like a unified diff to me... >The text leading up to this was: >-------------------------- >|--- fs/nfsserver/nfs_nfsdserv.c.savrecl 2018-02-10 20:34:31.166445000 -0500 >|+++ fs/nfsserver/nfs_nfsdserv.c 2018-02-10 20:36:07.947490000 -0500 >-------------------------- >Patching file fs/nfsserver/nfs_nfsdserv.c using Plan A... >No such line 4225 in input file, ignoring Hunk #1 succeeded at 4019 >(offset -207 lines). >doneSince it says "Hunk #1 succeeded...", I think it patched ok. However, you can check by looking at nfsrvd_reclaimcomplete() in sys/fs/nfsserver/nfs_nfsdserv.c. Before the patch it would look like: if (*tl == newnfs_true) nd->nd_repstat = NFSERR_NOTSUPP; else nd->nd_repstat = nfsrv_checkreclaimcomplete(nd); whereas after being patched, it will look like: nd->nd_repstat = nfsrv_checkreclaimcomplete(nd); if (*tl == newnfs_true) nd->nd_repstat = 0; rick [stuff snipped]
Rick Macklem
2018-Mar-05 01:16 UTC
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: 2The 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>