On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem <rmack...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
