Re: ESXi NFSv4.1 client id is nasty

From: Warner Losh <>
Date: Tue, 19 Jun 2018 08:16:11 -0600
On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem <> wrote:

> Steve Wills wrote:
> On 06/18/18 17:42, Rick Macklem wrote:
> >> Steve Wills wrote:
> >>> Would it be possible or reasonable to use the client ID to log a
> message
> >>> telling the admin to enable a sysctl to enable the hacks?
> >> Yes. However, this client implementation id is only seen by the server
> >> when the client makes a mount attempt.
> >>
> >> I suppose it could log the message and fail the mount, if the "hack"
> sysctl isn't
> >> set?
> >
> >I hadn't thought of failing the mount, just defaulting not enabling the
> >hacks unless the admin chooses to enable them. But at the same time
> >being proactive about telling the admin to enable them.
> >
> >I.E. keep the implementation RFC compliant since we wouldn't be changing
> >the behavior based on the implementation ID, only based upon the admin
> >setting the sysctl, which we told them to do based on the implementation
> ID.
> Well, without one of the hacks (as head currently is) the mounts always
> fail,
> so ESXi mounts failing is a feature of the "unhacked" server.
> (The ReclaimComplete failure fails the mount.)
> >Just an idea, maybe Warner's suggestion is a better one.
> Yes, I think Warner has the right idea, although logging a message w.r.t.
> the
> ReclaimComplete failure (which fails these mounts) when the hacks are
> turned
> off sounds like a good one to me.

I think so too, rate limited, with an invitation to turn on the hack :)

Received on Tue Jun 19 2018 - 12:16:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC