From owner-freebsd-fs@freebsd.org Mon Nov 7 20:48:25 2016 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 8DC33C35AD6 for ; Mon, 7 Nov 2016 20:48:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0057.outbound.protection.outlook.com [207.46.100.57]) (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 42638DC3 for ; Mon, 7 Nov 2016 20:48:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 12:14:11 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 12:14:11 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/qDNWAyAgAAWmcg= Date: Mon, 7 Nov 2016 12:14:10 +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-office365-filtering-correlation-id: 430ce072-1546-46c7-f61d-08d40707951c x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:1UmLvkwNQL1elmCZN+HsOiFrkUALLv9CukwaNBPL3wGME7PsdMVssG9e0vsCY0W50cu1itLY5koqJplyik3Ft4xoDkKnoPWYBP4uiFVj7a+GB0SRkEHUS5EfM6cnhhzAARwcCOSCCzDvd8dWrK6+CG3sDfQGByjVBhN2hyXO0tK36YdzCn7xqIEOSxs2E5bAIKuxh02RJwkEf7tESswj+hQMHCgj+impTDD1/UYwFXdTHIbR0RN+TbQR4KnvNHBmtoQyk7jsgelBqUafhtvdGOQc0dIWt0iOxfbVHU1E6RDIbaHSoiJfU1z0zGFZd+PstNKmDOzqrbMNsNqpXefFD2vT41m8XBR4GdGuQeLAllo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(51914003)(199003)(19580395003)(122556002)(7846002)(11100500001)(87936001)(6916009)(86362001)(19580405001)(4326007)(5660300001)(106356001)(76176999)(54356999)(97736004)(50986999)(3660700001)(189998001)(68736007)(9686002)(101416001)(74482002)(586003)(8676002)(5002640100001)(106116001)(15975445007)(77096005)(102836003)(2906002)(33656002)(3280700002)(7696004)(2900100001)(305945005)(92566002)(110136003)(8936002)(10400500002)(2950100002)(105586002)(81166006)(81156014)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.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) 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-originalarrivaltime: 07 Nov 2016 12:14:10.7065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:48:25 -0000 Doug Rabson wrote: > >It seems like a reasonably good idea to disable disable the mount protocol= if its not >needed. For NFSv4, mountd really doesn't do much other than re= ad the exports files and >push them into the kernel - does it even need to = keep running after that for NFSv4? Probably so that /etc/exports can be reloaded, but that would be the only r= eason, assuming "showmount" isn't being supported. > >On the subject of showmount, we do have some information on connected clie= nts which I >suppose you could try to expose but its probably not worth the= effort. Some clients (Solaris, I think) don't maintain TCP connections for inactive= mounts, so the connections aren't a direct indication of mounts. Thanks for the comments, rick On 6 November 2016 at 20:51, Rick Macklem > wrote: Hi, NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to try = and track mounts/unmounts and report exports to clients. Except for the one RPC= that maps a directory path to a File Handle, none of this is needed by NFS. The = rest is reported (and never guaranteed to be correct) by showmount(8). There are a couple of issues related to the Mount protocol. 1 - It uses a dynamically assigned port# via rpcbind (which means hassles f= or firewalls, etc). 2 - umount(8) currently assumes that it is supported over UDP and fails if = it is configured to work over TCP only. 3 - A recent issue was reported where there is a delay for systems configur= ed for IP6 only related to the handling of localhost. (I'll admit I didn't unders= tand quite why there was this 2sec delay, but others familiar with networking confirm= ed it was correct behaviour.) NFSv4 doesn't use the Mount protocol at all and does everything via the NFS= v4 protocol serviced at port #2049. I have never done anything about this, since most were still using NFSv3, b= ut it seems that maybe something should be done now? - What do people think of having a new option on mountd(8) that would be us= ed for NFSv4 only servers that disables servicing of Mount RPCs. --> This would imply that "showmount" would no longer work for it. --> Note that "showmount" returns nothing useful for NFSv4 mounts,= since mountd doesn't know about NFSv4 mounts (and the NFSv4 server doesn'= t know either, because there is no concept of a "mount" in the NFSv4 protoc= ol). --> It does imply that "showmount -e" will stop working and that in= fo might be useful w.r.t. NFSv4 servers. Umount(8) for NFSv3 is a slightly different problem. It has (for 30years) j= ust talked to UDP. If that doesn't work, there is a delay, but the umount still works (an= d the info from "showmount" is no longer correct, but it is never guaranteed to be cor= rect anyhow). - Should umount(8) use TCP if the NFSv3 mount is using TCP? --> This could cause it to break for a case where only UDP is supported f= or the Mount protocol on the server, but that would be a rare/broken case, I'd g= uess. Anyhow, any/all comments on this would be appreciated, rick _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"