From owner-freebsd-fs@freebsd.org Wed Nov 29 17:28:06 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A76FE5E968; Wed, 29 Nov 2017 17:28:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0078.outbound.protection.outlook.com [104.47.42.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 366C07D2AB; Wed, 29 Nov 2017 17:28:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM (52.132.40.149) by YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM (52.132.40.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 17:28:05 +0000 Received: from YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM ([fe80::937:f79d:d224:f68c]) by YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM ([fe80::937:f79d:d224:f68c%13]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 17:28:05 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPobgABJSsyAAAEe3oAA8S4AgAA7/Xs= Date: Wed, 29 Nov 2017 17:28:05 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> <20171128164132.290bf07218b16164db613242@bidouilliste.com> , <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com> In-Reply-To: <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com> 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; YTXPR0101MB2174; 6:X+KElzgTxw2koNR9Tk/TXXxcHJLyz5TanBBE9POSJHsb8MZ1Ed+BpHyfE1YEnENL6TbcDIdGq6a+g2idHtEBrMkdHLGnLeqOneChJv0UxLAYp/1GjJ8N+VPXKS3ftuDj2VrKwQd8wcirL0LVXyBBPI1cNkeNfj1G/UsmVLSEJ4o+wCkEW9SZc60hlQngZW99a8V2lUF5iCODYfMs8naLrNJsbM4ljWwHOEwZxiGRmAhuEevmGsbR9BBCJNY8h2T8+NphV3wrvvfzrycJWS/MB3/sQ60lvsqvFSVHI03ImwNKWDUVH01JRT4Oh8/F0LQx2TnoIh0MwKeG/BXpAbhcYLuaOxGbo+htgI46drNuEH4=; 5:l+fhTLQf4g4HHGlwuZX5dq6iI/oFugNMfoAOADhWnKAekh0A1JiVvXqabpMTi//mxss0H+jdfoKw+DvuwgZIYap/pWrRLufKK2WMRFKxAALqYD8RA8uyJSBJsQCpz71uDq4XEzjgfZSQXNa5W7RyduC5h5habxfA+zlKOmUCKOQ=; 24:2aBVIMwPeqdRJ3SqwwdI8iUoh5XT1Clfs3kcBJqehG7b5M/LzxRecXMa9zv3bIswrf+dvPM3o462r4x1Yigs0MQdq4oNwgkPakp7OWiPEbY=; 7:22dDdENp5S7eDkO4pAA8rYawG2m8F4jgNa1e9DQeTm2oM+sK7dngQ02IwCu+qH8YyLLQH8cfF+mt7kyBAIZhsLPy7ak1hCG4LDoNwZNUQjYAWiQVeFFO0ejSkRhddQu16W5pm9gTKrE/lYfj8OUSSz/Ad3g3hcJeXRfvsMILBuDYgkqJjUGzrmZ/I5sOLIbxDTfBQvx2R7Mv5uctvK3+7rch5qF98ZLgdozH3RHW8FajqjS+0D3rNq/l3IB6+lpx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fcb76366-f35a-4eb2-b302-08d5374e8cc7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603273); SRVR:YTXPR0101MB2174; x-ms-traffictypediagnostic: YTXPR0101MB2174: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:YTXPR0101MB2174; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTXPR0101MB2174; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39830400002)(366004)(346002)(199003)(24454002)(189002)(9686003)(2900100001)(86362001)(2950100002)(5250100002)(33656002)(5660300001)(39060400002)(93886005)(6916009)(189998001)(105586002)(101416001)(106356001)(478600001)(102836003)(4326008)(7696005)(8936002)(2906002)(305945005)(14454004)(8676002)(81166006)(53936002)(74482002)(99286004)(97736004)(81156014)(55016002)(3280700002)(3660700001)(6246003)(786003)(54906003)(229853002)(74316002)(68736007)(6506006)(25786009)(6436002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR0101MB2174; H:YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) 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: fcb76366-f35a-4eb2-b302-08d5374e8cc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 17:28:05.0417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB2174 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 17:28:06 -0000 Emmanuel Vadot wrote: [stuff snipped] > I haven't test by I can say that it will work, I actually wondered at >first doing that. The problem with this patch is what I tried to >describe in my first and following mails, since you can turn on and off >delegation you can still have delegation (so nfsrv_delegatecnt > 0) >even if the sysctl is =3D=3D 0. That's why I went to the tunable way, seem= s >cleaner to me as disabling delegation doesn't really disable them for >current client. Yes, if you have delegations enabled and then disable them, there will be delegations issued for a "while". During that time, the code in nfsrv_checkgetattr() does need to check for them. Since no new delegations will be issued, the outstanding ones will go away when the client chooses to return them. (You can force this on the client by doing a dismount/mount, at least for the FreeBSD client.) Alternately, rebooting the server forces the clients to "recover" delegatio= ns and, if they are disabled, that fails. (Actually the recover succeeds, but = with a flag set that tells the client it must return them asap.) All the tunable does is make it impossible to disable them without rebooting, but otherwise the effect is the same. I have a patch that keeps a separate counter for write delegations (which are the ones you care about) using atomics to maintain the value. (That will be similar but somewhat better than what this patch does.= ) rick [lots more snipped]=