sys/fs/nfsclient on RTEMS gets a bad seqid error with open

[Rick Macklem]

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.
A couple of possibilities:
- The FreeBSD client code depends on an exclusive lock on the vnode
   to serialize the Opens.
   --> 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.

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.

rick
ps: Getting this seqid stuff right was about the hardest part of
    implementing NFSv4.0 and it could still be buggy.

Any hints or help would be most welcome.

Thanks
Chris
_______________________________________________
freebsd-hackers at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"