From owner-freebsd-rc@freebsd.org Tue Jun 19 11:03:46 2018 Return-Path: Delivered-To: freebsd-rc@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 3D5AC1010B73 for ; Tue, 19 Jun 2018 11:03:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B9CB27A098 for ; Tue, 19 Jun 2018 11:03:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 789641010B53; Tue, 19 Jun 2018 11:03:45 +0000 (UTC) Delivered-To: rc@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 4ECC41010B52; Tue, 19 Jun 2018 11:03:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660066.outbound.protection.outlook.com [40.107.66.66]) (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 CB2377A094; Tue, 19 Jun 2018 11:03:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0956.CANPRD01.PROD.OUTLOOK.COM (52.132.44.27) 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:03:43 +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:03:43 +0000 From: Rick Macklem To: Don Lewis CC: "rc@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: review of nfsd rc.d script patch Thread-Topic: review of nfsd rc.d script patch Thread-Index: AQHUBOpJU2qX1eyBDUe5qiTFuEQ6AqRmwZYAgACsYVw= Date: Tue, 19 Jun 2018 11:03:43 +0000 Message-ID: References: , In-Reply-To: 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; YTOPR0101MB0956; 7:BcegBTxTG1KlthW113f2BQrsVxxfQWvxiZjY+JxYMQnHK1ezWigWkuuk/Ko1fGnhc/TgtgX7wJCB2+hovvQ93z5x9ZkYowCBoTkOo89YTLuJhm2WRNR0N9MvrGMA+qTzrdvmBcLNxTEaQF4C0w2Utv/lktAhFSA6Q/tefOIcO3ZD36bYYdnBYK09ukIMsNqGyLB9zfa7y+zpPliGCBOeDqb5YR1A4+XOVjIwOcDyocZflKx6JHxZO6l7e9ZfUHt7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d8a406b1-7e83-4067-40ca-08d5d5d4525c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0956; x-ms-traffictypediagnostic: YTOPR0101MB0956: 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)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0956; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0956; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(39380400002)(376002)(199004)(189003)(51444003)(478600001)(2900100001)(5660300001)(33656002)(14454004)(54906003)(81156014)(6916009)(76176011)(102836004)(186003)(486006)(81166006)(59450400001)(6506007)(68736007)(26005)(7696005)(86362001)(8936002)(476003)(8676002)(74316002)(25786009)(3280700002)(6436002)(4326008)(450100002)(446003)(2906002)(53936002)(11346002)(305945005)(3660700001)(9686003)(97736004)(99286004)(55016002)(786003)(106356001)(74482002)(6246003)(105586002)(5250100002)(316002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0956; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: FifB1xIcovfL721ZXXVkagdhRW9lzgbL60QaNp5I86CyknGycg293piQvI1yjFb8PFX00NXii4u/vxmE/O97xUTg9FwRfk8Gr/QvyFbea6Y6nsUruRwQkcyzN5aS0Jv1AkQj84AGO4eUycYwvEgK3OORldQmGmprKzrAsoF6VbdHm0mReibQ2VpnuYJEWVVpguqx8ja1EK1ZXktMT42a3+ggfcAz3SzwLc0hgmyygaUP+hxA6d/TX0npNcbQLcHmpkGvWR+vvHWthIueSEp/KlbIQCKDFYlQp3M7cdBf4j5GJ4Xy85vcLhnRxo4z3oDx 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: d8a406b1-7e83-4067-40ca-08d5d5d4525c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 11:03:43.3572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0956 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 11:03:46 -0000 Don Lewis wrote: >On 15 Jun, Rick Macklem wrote: >> Hi, >> >> For the pNFS service MDS machine, the nfsd can't be started until all nf= s mounts >> in /etc/fstab are done. >> I think that adding "mountcritremote" to the "# REQUIRE:" line is suffic= ient to do this? >> >> I don't think delaying the startup of the nfsd daemon until after any NF= S mounts >> are done will do any harm, but if others think it would be a POLA violat= ion, >> I could make this dependent on the pNFS service being enabled. >> Does anyone think this would cause a POLA violation? > >Sounds like that would break cross mounts. Back in the olden days >before the automounter, I would set up workstation clusters with hosta >exporting local filesystem /home/hosta, and hostb exporting /home/hostb. >In addition, hosta would do a bg NFS mount of /home/hostb and hostb >would do a bg NFS mount of /home/hosta. That way everybody would have a >consistent view of everything. If a power failure took down everything, >the first system up would export its local filesystem and even though it >wouldn't be able to mount any remote filesystems, mount would background >itself at the boot would complete. As the remaining machines came up, >they would be able to mount the remote filesystems of the machine that >came up earlier, and the early machines would mount the filesystems from >the later machines as they became available. > >If nfsd is delayed until all the NFS filesystems are mounted, the above >setup would deadlock. I think you would have used the "bg" mount option on the NFS mounts to get the above to work? (That is what makes the mount go "background" if it can'= t contact the NFS server.) If so, this would still behave the same after this patch. The patch forces "mountcritremote" to complete before nfsd is run (to be ho= nest, since "m" comes before "n", I think that happens anyhow? This patch just tr= ies to ensure that). It does not force waiting for mount completion if "bg" is specified. (Put another way, "bg" can't be used for mounts of DSs for the pNFS server = setup.) rick ps: I recall a small company that only had a few SGI workstations and did a= setup like the above. However, they weren't very good at configuring it and= , as such, everyone would run around for a half hour after a power failure, tryi= ng to get the workstations back up;-)