Date: Mon, 18 Jun 2018 17:55:08 -0400 From: Steve Wills <swills@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Cc: "andreas.nagy@frequentis.com" <andreas.nagy@frequentis.com> Subject: Re: ESXi NFSv4.1 client id is nasty Message-ID: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> In-Reply-To: <YTOPR0101MB0953070582B97A0B62B7A4FFDD710@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> References: <YTOPR0101MB0953E687D013E2E97873061ADD720@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> <d5f86680-6bd3-8513-b293-3fbab5b1277b@FreeBSD.org> <YTOPR0101MB0953070582B97A0B62B7A4FFDD710@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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. Just an idea, maybe Warner's suggestion is a better one. Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8ceea008-f827-580b-8ca6-4a5fcb028e83>