Date: Sat, 2 Jan 2021 23:58:49 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Chris Johns <chrisj@rtems.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Message-ID: <YQXPR0101MB0968BA1623FAB5DB28EC983CDDD40@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org> References: <YQXPR0101MB096874499E40F220D359B919DDD50@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>, <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Johns wrote:=0A= [stuff snipped]=0A= >Rick Macklem wrote:=0A= >> Did you do a Setclientid, Setclientidconfirm to set up the clientid?=0A= >=0A= >The nfsclient code by default seemed to do this but now I have set nfsv4 a= s an=0A= >option (required by minorversion) I get a different set of packets being= =0A= >exchanged. I will work with NFSv4.1.=0A= Yes. Setclientid, Setclientidcfrm is NFSv4.0 specific.=0A= For NFSv4.1 and 4.2, the clientid is created/confirmed by=0A= ExchangeID, CreateSession=0A= =0A= rick=0A= =0A= > The first Open should be fine with seqid=3D=3D0 and the reply will flag i= t=0A= > as "needs Openconfirm".=0A= > --> 10026 means the server thinks it has already seen the open_owner=0A= > string for that client.=0A= >=0A= > I'd suggest to capture a packet trace of a mount from the FreeBSD client= =0A= > and then look at it in wireshark, to see what should be happening.=0A= =0A= Yes and thanks, I am doing this. My lack of knowledge about the NFSv4 proto= col=0A= is the issue here :)=0A= =0A= >>> A couple of possibilities:=0A= >>> - The FreeBSD client code depends on an exclusive lock on the vnode=0A= >>> to serialize the Opens.=0A= >>=0A= >> There is only one open call active. This is something I can control.=0A= > If all your Opens are serialized, you can use a single open_owner for=0A= > everything. The open_owner string should always be the same to do=0A= > this.=0A= > The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown"=0A= > as a mount option.=0A= =0A= I had this set.=0A= =0A= >>> --> If what you are doing doesn't serialize them, then that will be = a=0A= >>> problem.=0A= >>> - If the VOP_OPEN() generates an unexpected error (I just ran into this= =0A= >>> on FreeBSD head), then the client might not get things correct.=0A= >>> --> The seqid is incremented for some errors, but not others.=0A= >>=0A= >> I am currently basing this work on the FreeBSD 12 branch we have. A mast= er port=0A= >> is next.=0A= >>=0A= >> Btw, all this seqid stuff goes away when you use NFSv4.1 and there=0A= >> are NFSv4.1 only clients out there. You might want to consider doing=0A= >> this. If I was writing the code now, there would be no NFSv4.0.=0A= >>=0A= >> Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked = into=0A= >> this but I could not figure out how.=0A= > minorversion=3D1 mount option, which sets nm_minorvers to 1.=0A= =0A= Ah yes I see it now. Thank you. I was required to set nfsv4 which is what I= want=0A= but it does make me wonder about the default version I was using. I would h= ave=0A= thought v4 would be the default. Maybe it is something in the defaults in= =0A= mount_nfs that I should take a look at.=0A= =0A= These settings seems to have resolved the situation and I have moved furthe= r and=0A= onto other issues related to the port of the lockmgr.=0A= =0A= Chris=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB0968BA1623FAB5DB28EC983CDDD40>