Re: ESXi NFSv4.1 client id is nasty

On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem <rmacklem_at_uoguelph.ca> 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 :)

Warner