From owner-svn-src-all@freebsd.org Fri Jan 19 23:24:47 2018 Return-Path: Delivered-To: svn-src-all@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 E022DECF067; Fri, 19 Jan 2018 23:24:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660042.outbound.protection.outlook.com [40.107.66.42]) (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 8405C7C368; Fri, 19 Jan 2018 23:24:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2171.CANPRD01.PROD.OUTLOOK.COM (52.132.46.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Fri, 19 Jan 2018 23:24:45 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::c45:e67:9188:fa40]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::c45:e67:9188:fa40%13]) with mapi id 15.20.0428.014; Fri, 19 Jan 2018 23:24:45 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Emmanuel Vadot , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r328129 - head/sys/fs/nfsserver Thread-Topic: svn commit: r328129 - head/sys/fs/nfsserver Thread-Index: AQHTkHERZLAcPGgud0iNHWvuSowXEaN5xAOAgABtS1KAANV4AIAAzZlZ Date: Fri, 19 Jan 2018 23:24:44 +0000 Message-ID: References: <201801181528.w0IFSnWm053535@repo.freebsd.org> <20180118163855.b0a55427709c52d0ec2482c9@bidouilliste.com> , <20180119115408.f333d3a6ec8d762e73f1d844@bidouilliste.com> In-Reply-To: <20180119115408.f333d3a6ec8d762e73f1d844@bidouilliste.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2171; 7:n3GfBKGEe8MizvBhRUxNKnN93b6vYAoolD75EnMukE3kvUmfSIWzTV64UoTP7ccOBIfUbm3ZIoc8UM5d1+GNIGQiERnyyQFxFrhQUuGBcuaVoQQvvBbeLsyqaRcU0CGfozoVolmK+f3RVqGMXq/l0zcaHSnKcxTgpRmbjNnrJhOJCqhiKXWEMcLa6sR2oQfVQdzhPTUP2nsMJhjJnnsqgWxwmc/YqhAQwPrMcTE+JG+NDWrzHq3d0niT5Vca91rx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e078e487-4bcb-4910-693c-08d55f93d326 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:YTOPR0101MB2171; x-ms-traffictypediagnostic: YTOPR0101MB2171: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040498)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041285)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:YTOPR0101MB2171; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2171; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(376002)(39860400002)(396003)(346002)(189003)(199004)(229853002)(6246003)(6346003)(54906003)(2900100001)(305945005)(74482002)(105586002)(5250100002)(3660700001)(2906002)(8676002)(97736004)(59450400001)(99286004)(3280700002)(74316002)(5660300001)(6436002)(9686003)(25786009)(93886005)(86362001)(81166006)(33656002)(2950100002)(4326008)(106356001)(81156014)(76176011)(55016002)(7696005)(68736007)(102836004)(786003)(14454004)(53936002)(478600001)(316002)(8936002)(26005)(6916009)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2171; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-antispam-message-info: ynAyBUvyInGMD7x6OyhrYt0Rd4kwSZgOHC8IGfM/TOqSYV+WxBkv83A+ga9umEwV4MsTepkXHI0E4kXga1e4Yg== 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: e078e487-4bcb-4910-693c-08d55f93d326 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 23:24:44.9665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2171 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 23:24:48 -0000 Emmanuel Vadot wrote: [stuff snipped] > So should we warn once or maybe return EBUSY on unloading if there is >still lock structures ? My intent was that a module unload would clear out all data structures, so I would so no. I would also say that I envisioned an unload of nfsd.ko a= s a last resort, to free up the data structures. It should refuse to unload if the nfsd daemon is running. Isolan used to unload/load the nfsd.ko a lot, because they preferred that for testing and software updates. I, personally, have never done so (except once in a while to see if it work= s), so I'll admit I have trouble understanding why you would do so? Rebooting an NFSv4 server when clients are mounted forces the clients to do state recovery during a grace period (2 minutes+) right after boot. This isn't something that I would recommend as a routine exercise, but at least it should recover the opens/locks if it goes smoothly. (I can't recall for sure, but I don't think an unload/reload of the nfsd.ko followed by a startup of the nfsd daemon does this? If I am wrong and it does do this, then this is exactly like a reboot w.r.t. nfs service. If you look at a packet trace in wireshark just after the server restart, you would see errors like NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, NFS4ERR_BAD_SESSION that indicates to the client that recovery of state is needed. --> If this state recovery isn't happening then your mounts will probably b= e broken, at least w.r.t. byte range locking. If the unload/reload doesn't do this, then a reboot is preferable. Because of this rather complex state recovery exercise, any reboot or unload/reload/restart of the nfsd should be done only when absolutely necessary, imho. If you can't run a server for an extended period with an unload of the nfsd.ko or a reboot, using NFSv3 mounts would be a safer bet. I wrote: > For this case, normally all lock structures should go away when clients > unmount and unloading the nfsd module while there are active mounts > is not a safe practice. (Again NFSv4 isn't like NFSv3, there is server st= ate > for NFSv4.) > > rick rick