NFSv4.1 server deficiencies fixed for ESXi client

[Rick Macklem]

Hi,

Since I posted w.r.t. issues that seem to violate the RFC, I figured I should also
post ones that identified deficiencies in the FreeBSD server. These have either
been patched in head/current or will be soon and will be MFC'd.

- BindConnectiontoSession wasn't implemented. It is never used by the FreeBSD
client and not used during normal operation of the Linux client.
--> Now in head and will be MFC'd soon.
- OPEN_SHARE_ACCESS_WANT_NO_DELEG flag generated an error when set for
OpenDowngrade. Since OpenDowngrade never issues a delegation, no other client
sets this flag. However, since the RFC doesn't forbid it, the code in head now just
clears/ignores the flag instead of generating an error.
- ESXi client generates warnings that "2" is not a valid reason for not issuing
a delegation. Since "2" is in the list and the RFC says nothing about when each
reason is used, I don't know why it thinks it isn't valid. However, a patch that changes
the reason makes it happy and since other clients don't seem to care, this patch
will probably go in head soon.
(Until then, all it does is generate warnings.)

rick

[Rodney W. Grimes]

> Hi,
>
> Since I posted w.r.t. issues that seem to violate the RFC, I figured I should also
> post ones that identified deficiencies in the FreeBSD server. These have either
> been patched in head/current or will be soon and will be MFC'd.
>
> - BindConnectiontoSession wasn't implemented. It is never used by the FreeBSD
> client and not used during normal operation of the Linux client.
> --> Now in head and will be MFC'd soon.
> - OPEN_SHARE_ACCESS_WANT_NO_DELEG flag generated an error when set for
> OpenDowngrade. Since OpenDowngrade never issues a delegation, no other client
> sets this flag. However, since the RFC doesn't forbid it, the code in head now just
> clears/ignores the flag instead of generating an error.
> - ESXi client generates warnings that "2" is not a valid reason for not issuing
> a delegation. Since "2" is in the list and the RFC says nothing about when each
> reason is used, I don't know why it thinks it isn't valid. However, a patch that changes
> the reason makes it happy and since other clients don't seem to care, this patch
> will probably go in head soon.
> (Until then, all it does is generate warnings.)

Have you any contact with VMWare so that they might fix the issues
in thier code, rather than having to put hacks in FreeBSD for these
issues?

Thanks,
--
Rod Grimes ***@freebsd.org

[Rick Macklem]

Rodney W. Grimes wrote:
[stuff snipped]
>Have you any contact with VMWare so that they might fix the issues
>in their code, rather than having to put hacks in FreeBSD for these
>issues?
Nope. I tried an email to ***@ietf.org about one issue (that isn't yet resolved
related to it complaining that a directory changes too many times when stuff is
being deleted from it) in the hopes that someone that worked on the client
would respond, but no one made any technical comments on the post.

Andreas mentioned that his company might have some sort of maintenance
agreement so he could give them a bug report, but I don't think he's had any
opportunity to do that?

To be honest, I'm amazed it works with any NFSv4.1 server, but apparently it
does?

So if anyone can get the list of problems in the "ESXi NFSv4.1 client is nasty"
post to VMware's engineering people, it would be appreciated.

Thanks, rick