From owner-freebsd-fs@freebsd.org Fri Nov 11 22:25:44 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 8A8D2C3CAA7 for ; Fri, 11 Nov 2016 22:25:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0094.outbound.protection.outlook.com [157.56.110.94]) (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 213421870 for ; Fri, 11 Nov 2016 22:25:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Fri, 11 Nov 2016 22:25:35 +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.013; Fri, 11 Nov 2016 22:25:35 +0000 From: Rick Macklem To: Jason Mader , "freebsd-fs@freebsd.org" Subject: Re: Mount protocol/showmount vs NFSv4 Thread-Topic: Mount protocol/showmount vs NFSv4 Thread-Index: AQHSOG1Vi/9I8/Ov0UO2Epz4od6j/qDQvUCAgAOmbMw= Date: Fri, 11 Nov 2016 22:25:35 +0000 Message-ID: References: , <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> In-Reply-To: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> 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-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:ijb+jk1pT936XKxhuHzAy86YAszT4r5ehkynNMA7lrsUes2V7cVyhjbqtYSrhl+DE3C/T4qSo30e5AfoQI71lvpzqcZ7lHiZXuTMIxpccipyJ06axaqW6PNgPzBN41VocGb+1oXV5uz6sifC3ivHW1ILn17PMMOwDGtPH1hqVI+A95+UMaiMgvS0pEmkOyB6PVsFdmFAe3zFAvHNaJLQwXRPhrulb+JJ1yCcpqYwyTo/emlogH+4HZ4vxi6uqqCZBYeqs09uT8K2Ee80EHPG8EomDPRP151QbMd8/hItLp8lttLGJuh0AomlUpE0Duw8SAwDJYSAzHM+baEU4XdqwoDW1zHCw4E+hqavxb9BByk= x-ms-office365-filtering-correlation-id: f9e751f8-467f-4eac-258e-08d40a81a817 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374)(13783010486086); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(81166006)(8676002)(81156014)(74482002)(8936002)(2171001)(7696004)(74316002)(5660300001)(3280700002)(77096005)(101416001)(87936001)(229853002)(7846002)(8666005)(3660700001)(122556002)(2501003)(2950100002)(305945005)(9686002)(586003)(105586002)(106356001)(106116001)(86362001)(102836003)(2906002)(107886002)(97736004)(5001770100001)(68736007)(76176999)(50986999)(54356999)(92566002)(2900100001)(33656002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 22:25:35.0998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 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: Fri, 11 Nov 2016 22:25:44 -0000 I have just put a patch for umount(8) here that makes it do the Unmount RPC= over TCP for NFSv3/TCP mounts and not do the Unmount RPC for NFSv4 mounts. reviews.freebsd.org/D8503 Colin, maybe you could review this? Thanks, rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of Jason Mader Sent: Wednesday, November 9, 2016 9:39:19 AM To: freebsd-fs@freebsd.org Subject: Re: Mount protocol/showmount vs NFSv4 On 6 Nov 2016, at 15:51, Rick Macklem wrote: > 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 for 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 > configured for IP6 > only related to the handling of localhost. (I'll admit I didn't > understand quite why > there was this 2sec delay, but others familiar with networking > confirmed it was > correct behaviour.) > > NFSv4 doesn't use the Mount protocol at all and does everything via > the NFSv4 protocol > serviced at port #2049. > I have never done anything about this, since most were still using > NFSv3, but it seems > that maybe something should be done now? > - What do people think of having a new option on mountd(8) that would > be used 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 > protocol). > --> It does imply that "showmount -e" will stop working and > that info might be > useful w.r.t. NFSv4 servers. > > Umount(8) for NFSv3 is a slightly different problem. It has (for > 30years) just talked to > UDP. If that doesn't work, there is a delay, but the umount still > works (and the info > from "showmount" is no longer correct, but it is never guaranteed to > be correct 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 for the Mount > protocol on the server, but that would be a rare/broken case, > I'd guess. > > Anyhow, any/all comments on this would be appreciated, rick I agree that the NFS client can be improved to not try to contact the RPC server for an NFSv4 mount. The Linux NFS client already doesn=92t. A possible bug: the NFS server picks up it=92s NFSv4-only behavior from vfs.nfsd.server_min_nfsvers, but nfsd still registers 2 & 3 with rpcbind, 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100003 2 tcp6 ::.8.1 nfs superuser 100003 3 tcp6 ::.8.1 nfs superuser In nfsd.c the value of vfs.nfsd.server_min_nfsvers is not checked before registering sockets with rpcbind. In my use, I would like mountd to adjust it=92s behavior when vfs.nfsd.server_min_nfsvers > 3 and, by default, only listen on 127.0.0.1 and ::1. When additional addresses are needed they could then be added by the existing -h flag. Then mountd may not need to register the sockets with rpcbind at all. Then starting rpcbind could be eliminated to run an NFSv4-only server. (Guard the force_depend rpcbind in mountd and nfsd command scripts) `showmount -e` will still want to contact an RPC server though. Even when NFSv4-only, I=92m currently using the output of `showmount -E` to obtain the list of filesystems that already are automatically exported with the ZFS property sharenfs. This is because I need an additional -network flag on each filesystem, scripted when /etc/zfs/exports changes, and haven=92t found a better way to get two -network flags per filesystem. There is a possible improvement to ZFS when sharenfs has multiple -network flags, to write them as additional lines in /etc/zfs/exports. Then I would have no need for showmount at all, or for it=92s behavior to be changed. But the two minute delay on `showmount -e` happens when rpcbind is started with the -6 flag. This is being called correct behavior, but it is rather odd behavior on the transition to IPv6-only. -- Jason Mader _______________________________________________ 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"