Date: Sun, 3 Jan 2021 10:45:09 +1100 From: Chris Johns <chrisj@rtems.org> To: Rick Macklem <rmacklem@uoguelph.ca> 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: <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org> In-Reply-To: <YQXPR0101MB096874499E40F220D359B919DDD50@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR0101MB096874499E40F220D359B919DDD50@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/1/21 12:09 pm, Rick Macklem wrote: >> On 31/12/20 10:04 am, Rick Macklem wrote: >>> Chris Johns wrote: >>>> Hello, >>>> >>>> I am porting the kernel's nfsclient file system to the RTEMS port of FreeBSD. I >>>> have ported across the FreeBSD file descriptors, VFS and NFS code. I have a >>>> custom pseudofs file system as my root file system and I can mount an NFSv4 >>>> mount exported from a FreeBSD 12 box. >>>> >>>> When I open a file there are a some getattr RPC calls that are successful >>>> however the open call (PUTFH, OPEN, GETATTR) results in the server returning the >>>> bas seqid (10026) error code for the OPEN and I am not sure why this is >>>> happening. I suspect I am missing a step in the nfsclient set up. >>> Well, for NFSv4.0 Opens, there is a field in the open_owner called a "seqid', >>> which is used to serialize Open calls. If that "seqid" gets screwed up, you >>> get a "bad seqid" (10026) from the server and your mount is broken. >> >> There is only one open call being made and the seq id in the packet is 0. The >> server code seems to consider ownership when returning this error and this is an >> area I am not sure about. RTEMS simulates a process and does not have a normal >> user/group model. > Did you do a Setclientid, Setclientidconfirm to set up the clientid? The nfsclient code by default seemed to do this but now I have set nfsv4 as an option (required by minorversion) I get a different set of packets being exchanged. I will work with NFSv4.1. > The first Open should be fine with seqid==0 and the reply will flag it > as "needs Openconfirm". > --> 10026 means the server thinks it has already seen the open_owner > string for that client. > > I'd suggest to capture a packet trace of a mount from the FreeBSD client > and then look at it in wireshark, to see what should be happening. Yes and thanks, I am doing this. My lack of knowledge about the NFSv4 protocol is the issue here :) >>> A couple of possibilities: >>> - The FreeBSD client code depends on an exclusive lock on the vnode >>> to serialize the Opens. >> >> There is only one open call active. This is something I can control. > If all your Opens are serialized, you can use a single open_owner for > everything. The open_owner string should always be the same to do > this. > The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown" > as a mount option. I had this set. >>> --> If what you are doing doesn't serialize them, then that will be a >>> problem. >>> - If the VOP_OPEN() generates an unexpected error (I just ran into this >>> on FreeBSD head), then the client might not get things correct. >>> --> The seqid is incremented for some errors, but not others. >> >> I am currently basing this work on the FreeBSD 12 branch we have. A master port >> is next. >> >> Btw, all this seqid stuff goes away when you use NFSv4.1 and there >> are NFSv4.1 only clients out there. You might want to consider doing >> this. If I was writing the code now, there would be no NFSv4.0. >> >> Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked into >> this but I could not figure out how. > minorversion=1 mount option, which sets nm_minorvers to 1. Ah yes I see it now. Thank you. I was required to set nfsv4 which is what I want but it does make me wonder about the default version I was using. I would have thought v4 would be the default. Maybe it is something in the defaults in mount_nfs that I should take a look at. These settings seems to have resolved the situation and I have moved further and onto other issues related to the port of the lockmgr. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?888017f2-eea6-12f9-fb24-04a1e1d95ea8>