NAGY Andreas wrote:
>Thanks! Please keep me updated if you find put more or when a updated version
>is available.
Will try to remember to do so.
>As I now know it is working, I will start tomorrow to build up a testsystem
>with 3 NFS servers >(two of them in a ha with CARP and HAST) and several
FS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client
NAGY Andreas wrote:
>Thanks, the not issuing delegation warnings disappeared with this patch.
>
>But now there are some new warnings I haven't seen so far:
>2018-03-10T13:01:39.441Z cpu8:68046)WARNING: NFS41: NFS41FSOpGetObj
NAGY Andreas wrote:
>Thanks, the not issuing delegation warnings disappeared with this patch.
>
>But now there are some new warnings I haven't seen so far:
>2018-03-10T13:01:39.441Z cpu8:68046)WARNING: NFS41: NFS41FSOpGetObject:2148:
>Failed to >get object 0x43910e71b386 [36 c6b10167 9b157f95
Thanks, the not issuing delegation warnings disappeared with this patch.
But now there are some new warnings I haven't seen so far:
2018-03-10T13:01:39.441Z cpu8:68046)WARNING: NFS41: NFS41FSOpGetObject:2148:
Failed to get object 0x43910e71b386 [36 c6b10167 9b157f95 5aa100fb 8ffcf2c1 c 2
NAGY Andreas wrote:
>>I'll take another look and see if I can guess why it doesn't like "2" as a
>>reason for >not issuing a delegation. (As noted before, I don't think this is
>>serious, but???)
>
>This warnings are still there, but don't seem to have any impact. It looks
>like they >only
>The attached patch changes BindConnectiontoSession to reply
>NFS4ERR_BAD_SESSION when the session doesn't exist. This might trigger
>recovery after a server reboot.
>This patch must be applied after bindconn.patch.
Works perfect! ESXi host reconnects to the datastore as soon as the nfsserver
NAGY Andreas wrote:
>Actually I have only made some quick benchmarks with ATTO in a Windows VM
>>which has a vmdk on the NFS41 datastore which is mounted over two 1GB links
>in >different subnets.
>Read is nearly the double of just a single connection and write is just a bit
>faster. >Don't
NAGY Andreas wrote:
>- after a reboot of the FreeBSD machine the ESXi does not restore the NFS
>>datastore again with following warning (just disconnecting the links is fine)
>2018-03-08T12:39:44.602Z cpu23:66484)WARNING: NFS41:
> >NFS41_Bug:2361: BUG - Invalid
NAGY Andreas wrote:
>Thanks you, really great how fast you adapt the source/make patches for this.
>Saw so many >posts were people did not get NFS41 working with ESXi and FreeBSD
>and now I have it already >running with your changes.
>
>I have now compiled the kernel with all 4 patches, and it
'freebsd-stable@freebsd.org'
<freebsd-stable@freebsd.org>
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client
NAGY Andreas wrote:
>attached the trace. If I see it correct it uses FORE_OR_BOTH.
>(bctsa_dir: >CDFC4_FORE_OR_BOTH (0x0003))
Yes. T
NAGY Andreas wrote:
>attached the trace. If I see it correct it uses FORE_OR_BOTH. (bctsa_dir:
>>CDFC4_FORE_OR_BOTH (0x0003))
Yes. The scary part is the ExchangeID before the BindConnectiontoSession.
(Normally that is only done at the beginning of a new mount to get a ClientID,
followed
acklem [mailto:rmack...@uoguelph.ca]
Sent: Mittwoch, 7. März 2018 16:07
To: NAGY Andreas <andreas.n...@frequentis.com>; 'freebsd-stable@freebsd.org'
<freebsd-stable@freebsd.org>
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client
NAGY Andreas wrote:
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
NAGY Andreas wrote:
>Compiling with the last patch also failed:
>
>error: use of undeclared identifier 'NFSV4OPEN_WDSUPPFTYPE
If you apply the attached patch along with wantdeleg.patch, it should
build. At most, this will get rid of the warnings about invalid reason for
not issuing a delegation,
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
em; 'freebsd-stable@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
acklem [mailto:rmack...@uoguelph.ca]
Sent: Montag, 5. März 2018 02:16
To: NAGY Andreas <andreas.n...@frequentis.com>; 'freebsd-stable@freebsd.org'
<freebsd-stable@freebsd.org>
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client
NAGY Andreas wro
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 f
: Montag, 5. März 2018 02:16
To: NAGY Andreas <andreas.n...@frequentis.com>; 'freebsd-stable@freebsd.org'
<freebsd-stable@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 sa
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
iSCSI but not as slow as it is now.
andi
-Original Message-
From: Rick Macklem [mailto:rmack...@uoguelph.ca]
Sent: Sonntag, 4. März 2018 06:48
To: NAGY Andreas <andreas.n...@frequentis.com>; freebsd-stable@freebsd.org
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in
-Original Message-
From: Rick Macklem [mailto:rmack...@uoguelph.ca]
Sent: Sonntag, 4. März 2018 06:48
To: NAGY Andreas <andreas.n...@frequentis.com>; freebsd-stable@freebsd.org
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi
client
NAGY Andreas wrot
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
v.c 4102
lines.
andi
-Original Message-
From: Rick Macklem [mailto:rmack...@uoguelph.ca]
Sent: Samstag, 3. März 2018 03:01
To: NAGY Andreas <andreas.n...@frequentis.com>; freebsd-stable@freebsd.org
Subject: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESX
NAGY Andreas wrote:
>I am trying to get a FreeBSD NFS 4.1 export working with VMware Esxi 6.5u1,
>but >it is always mounted as read only.
>
>After some research, I found out that this is a known problem, and there are
>>threads about this from 2015 also in the mailinglist archive.
>
>As it seems
Hi,
I am trying to get a FreeBSD NFS 4.1 export working with VMware Esxi 6.5u1, but
it is always mounted as read only.
After some research, I found out that this is a known problem, and there are
threads about this from 2015 also in the mailinglist archive.
As it seems VMware will not change
26 matches
Mail list logo
