From owner-freebsd-current@freebsd.org Tue Jun 19 11:11:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F132B1011326 for ; Tue, 19 Jun 2018 11:11:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670049.outbound.protection.outlook.com [40.107.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E157A5C0; Tue, 19 Jun 2018 11:11:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0794.CANPRD01.PROD.OUTLOOK.COM (52.132.47.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Tue, 19 Jun 2018 11:11:08 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 11:11:08 +0000 From: Rick Macklem To: Steve Wills , "freebsd-current@freebsd.org" CC: "andreas.nagy@frequentis.com" Subject: Re: ESXi NFSv4.1 client id is nasty Thread-Topic: ESXi NFSv4.1 client id is nasty Thread-Index: AQHUBjX1G4uSBXqIhUeci7+GbxFK06RmiCEAgAAFxoiAAAO4AIAA3Phc Date: Tue, 19 Jun 2018 11:11:08 +0000 Message-ID: References: , <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> In-Reply-To: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0794; 7:NqNyJfk8jzRqhcvGDeLHsLul+xBTvUj862D9mlMHpOJ0aT2GXkssifebXcpCVjw4WbZPE4Ml8qtmLkDV/KCwPD3hR9Ldt1/fvDFBk/V3k3QUuozT7zXzfXugQ7C+a3ue+z/eHvKWjnefmfefdTbbE7sCo9P/lC7ltjP2DNULBo5mE86wdo/9uPYEtfMwQcAWwqqIS/9FZNphtfqKktg4NiQaIshgbTyHOa3E+QAAjzXCvaQ1cBrZBxR0L+2xswXJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 050eb44b-a3e3-483c-296b-08d5d5d55bc5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0794; x-ms-traffictypediagnostic: YTOPR0101MB0794: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0794; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0794; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(39860400002)(39380400002)(396003)(189003)(199004)(102836004)(26005)(7696005)(476003)(186003)(76176011)(99286004)(105586002)(3280700002)(106356001)(3660700001)(2900100001)(478600001)(59450400001)(53546011)(6506007)(2906002)(5660300001)(2501003)(11346002)(486006)(86362001)(5250100002)(446003)(33656002)(74316002)(53936002)(316002)(55016002)(786003)(4326008)(74482002)(6436002)(97736004)(229853002)(9686003)(25786009)(81166006)(14454004)(8936002)(81156014)(68736007)(6246003)(93886005)(8676002)(110136005)(305945005)(12363001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0794; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: T4vGA4ieJHlfBxf9gsAgi/m9hhL/fn79xMxdkdJWV66pxqdcydfLJSjeMVNe1Emkf+SWPPS97LsAZ2k2VQjEwD0uO59NInMAvMgZcJzGWcrkbNo/au56fRM5oeso7N1aLOFX6X8dLTQBPdbE4E2pDQUcT989UIzx8D5ByAxPCY3cgjWyjmMI25EZ5p18KK6v70PI/J0TTfUDaLV8zxbRbaHH2MhMSHoUZRW52hJbWne1MEAa5AyGTFfeZJcmFBk3xDeFqU18Zg8/KmIj4ZDxRsk2d6/nq4wRo5wpKDKphHbj0npVffYqyQO4SmIFBG7UcT3uilwERaL/IzkOKccydw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 050eb44b-a3e3-483c-296b-08d5d5d55bc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 11:11:08.6722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0794 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 11:11:10 -0000 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 messag= e >>> 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" sys= ctl 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 I= D. Well, without one of the hacks (as head currently is) the mounts always fai= l, 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. t= he ReclaimComplete failure (which fails these mounts) when the hacks are turne= d off sounds like a good one to me. >Steve rick