From owner-freebsd-fs@freebsd.org Sat Nov 12 09:41:12 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 196C0C3B004 for ; Sat, 12 Nov 2016 09:41:12 +0000 (UTC) (envelope-from 0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEE48197A for ; Sat, 12 Nov 2016 09:41:11 +0000 (UTC) (envelope-from 0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1478943670; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=BTKx/HFmGiQK83oYAg8Z6hrfR+2x5z9echX/ax1Jkbg=; b=VHhBRYAz/vvwXaME4s47H6Y44tXvX0f/5dhIm2pTeAqZ1k8AC0JbgHJHJguylmx1 5+HOsVi/GBI7aCCU4628XcX70KhAuigSmBtYSD5+8lDQcPsQH+wsCyVmv/mylAZ4k8h O1VqOUgeYnCXvOwNf3N9e75HNqYU1Pympy4N8OHM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1478943670; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=BTKx/HFmGiQK83oYAg8Z6hrfR+2x5z9echX/ax1Jkbg=; b=ZupVSZ+IkDKkBqsEXRZCnA8IxHTa8OWt/kE1MpGgimtiZ5gD9Gk9l2JByn7zH6/I nsFCNSWiOijvVuP4625PQhkTdOE4Zm7zbYEORVwe5bZ6kDdRFu/wisjEShWbIzkNg1y 0mMckb/nCkrq6N0cxlACOZXGXiCPHA7l8TvK63L4= Subject: Re: Mount protocol/showmount vs NFSv4 To: Rick Macklem , Jason Mader , "freebsd-fs@freebsd.org" References: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> From: Colin Percival Message-ID: <0100015857e97ed8-b45e0929-6c68-4e67-9bc5-31b5a95dd9b7-000000@email.amazonses.com> Date: Sat, 12 Nov 2016 09:41:10 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2016.11.12-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES 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: Sat, 12 Nov 2016 09:41:12 -0000 On 11/11/16 14:25, Rick Macklem wrote: > 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? Aside from one very minor bug, it works fine for NFSv4. But I can't confirm about other NFS versions. Colin Percival > ________________________________________ > 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�t. > > A possible bug: the NFS server picks up it�s 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�s 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�m 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�t 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�s 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" > _______________________________________________ > 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" > > -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid