[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open
From:       Rick Macklem <rmacklem () uoguelph ! ca>
Date:       2021-01-02 23:58:49
Message-ID: YQXPR0101MB0968BA1623FAB5DB28EC983CDDD40 () YQXPR0101MB0968 ! CANPRD01 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

Chris Johns wrote:
[stuff snipped]
>Rick Macklem wrote:
>> 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.
Yes. Setclientid, Setclientidcfrm is NFSv4.0 specific.
For NFSv4.1 and 4.2, the clientid is created/confirmed by
ExchangeID, CreateSession

rick

> 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]