From owner-freebsd-fs@FreeBSD.ORG Wed Sep 21 23:50:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155E4106564A for ; Wed, 21 Sep 2011 23:50:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C5AF88FC16 for ; Wed, 21 Sep 2011 23:50:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAGd3ek6DaFvO/2dsb2JhbABChFyhJoJggVMBAQQBIwRSBRYOCgICDRkCWQaICqJ4kXCBLIRAgREEk02RSw X-IronPort-AV: E=Sophos;i="4.68,420,1312171200"; d="scan'208";a="135387600" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 Sep 2011 19:50:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D41C7B3F1F; Wed, 21 Sep 2011 19:50:54 -0400 (EDT) Date: Wed, 21 Sep 2011 19:50:54 -0400 (EDT) From: Rick Macklem To: Robert Schulze Message-ID: <373396436.1795807.1316649054817.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4E789BC7.3090702@bytecamp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFS umount takes ages when no DNS available X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:50:56 -0000 Robert Schulze wrote: > Hi, > > during maintainance work, I realized that an umount -h ip.ad.re.ss > takes > very long time when there is no nameserver reachable by the client > (and > server). All nfs configuration is done without hostnames, so I wonder > why there is this delay (about 1 minute per mountpoint). > Well, here is the code snippet. (I'm not sure why the author felt that the getaddinfo() needed to be done before the check for the need to do an rpc?): if (hostp != NULL) { 341 *delimp = '\0'; 342 getaddrinfo(hostp, NULL, &hints, &ai); 343 if (ai == NULL) { 344 warnx("can't get net id for host"); 345 } 346 } 347 348 /* 349 * Check if we have to start the rpc-call later. 350 * If there are still identical nfs-names mounted, 351 * we skip the rpc-call. Obviously this has to 352 * happen before unmount(2), but it should happen 353 * after the previous namecheck. 354 * A non-NULL return means that this is the last 355 * mount from mntfromname that is still mounted. 356 */ 357 if (getmntentry(sfs->f_mntfromname, NULL, NULL, 358 CHECKUNIQUE) != NULL) 359 do_rpc = 1; Just to clarify, umount(8) does do an rpc against the server, but it isn't very important. All it does is tell the server to remove an entry from the table it uses to generate replies to showmount(8). NFS itself doesn't care about this table. If you do a # umount /mnt and the server name can't be resolved via DNS, you can C out and the mount point will be gone in the client. (As above, I'm not sure why the author felt that the getaddrinfo() should be done before the umount(2) for the "-h" case. As such, I would be hesitant to change it.. Even if you change it, it would need to be done later, so the RPC to the server can be performed. The C trick would then work, but only if there was only one mount point on the server. > client: 8.1-RELEASE-p1/amd64 > server: 8.2-STABLE/amd64 > > The hostname seems to be exchanged by client and server, this can be > noticed by warnings like the following in /var/log/messages on the > server: > > rpc.statd: Failed to contact host client.foobar.net: RPC: Port mapper > failure - RPC: Timed out > > statd is running on the client, but bound to an interface with an ip > address not matching the logged hostname. > > Could NFS be tweaked in that way, that it does not use hostnames at > all > or at least will not provide hostnames on interfaces with don't carry > the ip address the hostname matches to? > I don't know if the hostnames are in arguments on the wire for the Network Status Monitor (NSM) and Network Lock Manager (NLM) protocols. To find out, you'll probably need to read the sources, since there isn't any RFCs for these. (They were eventually published in an X/Open manual, but in the old days, you had to buy it hardcopy, since that was a funding source for X/Open.) These protocols were done in the days when servers would have been in /etc/host files, so the names always resolved. (mid to late 1980s) rick