From owner-freebsd-fs@FreeBSD.ORG Fri Jul 8 19:58:05 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 AEF3B106564A for ; Fri, 8 Jul 2011 19:58:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6799D8FC0C for ; Fri, 8 Jul 2011 19:58:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAE1gF06DaFvO/2dsb2JhbABUhEKkBrkZkDuBK4QAgQ0EkkyQYA X-IronPort-AV: E=Sophos;i="4.65,500,1304308800"; d="scan'208";a="130282992" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Jul 2011 15:58:04 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2D1C2B3E95; Fri, 8 Jul 2011 15:58:04 -0400 (EDT) Date: Fri, 8 Jul 2011 15:58:04 -0400 (EDT) From: Rick Macklem To: Martin Birgmeier Message-ID: <1489296886.367033.1310155084168.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201107081310.p68DA3Nj019275@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes NFS to fail 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: Fri, 08 Jul 2011 19:58:05 -0000 Martin Birgmeier wrote: > The following reply was made to PR kern/131342; it has been noted by > GNATS. > > From: Martin Birgmeier > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/131342: [nfs] mounting/unmounting of disks causes > NFS to > fail > Date: Fri, 08 Jul 2011 15:00:03 +0200 > > This is a friendly reminder that some kind soul with knowledge of the > relevant kernel parts look into this... the error can easily be > reproduced. I just had it on a 7.4 system which did heavy reading from > an 8.2 server. When I mounted something on the server, the client got > a > "Permission denied" reply. > > So, to recap the scenario: > > 7.4 NFS client > 8.2 NFS server > client mounts a fs from the server (via IPv4, might be interesting to > look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/151681, too, > but > that is unrelated) > client does heavy i/o on the mounted fs > server does a mount (on its side, in this case it was from an md > device) > > --> error: client gets back some NFS error (in this case "permission > denied") > I just made a quick attempt and wasn't able to reproduce this. I mounted/unmounted a UFS volume on the server (both to a subdir of the exported volume and to a directory outside of the exported volume) while a client as accessing an exported fs and didn't get an error. Could the way you mount the volume on the server somehow end up renumbering the exported volumes? If so, the fsid in the file handle will no longer be able to vfs_busyfs(fsid); - and then the mount point will be broken until remounted by the client. I don't use anything like geom and don't use ZFS. Since you can reproduce this easily, I'd suggest that you: 1 - look to make sure drives (the st_dev value returned by stat(2)) aren't being renumbered by the mount. (If they are, then that has to be avoided if an NFS export is to still work.) 2 - Try mounting/unmounting something else, to see if it is md specific. Also, does it only happen when there is a heavy load generated by the client or all the time? (If only under heavy load, it may be a mount list locking bug, since that's the only place where a mount of a non-exported volume on the server will affect the exported mounts, as far as I can see.) I don't mind looking at a packet trace (you can email me the file generated by "tcpdump -s 0 -w host " when run on the server, but only if you can reproduce it without the heavy client load. (If only reproduced when there is a heavy client load a packet trace would be too big and probably not useful, since the bug is likely some race related to the mount list.) rick ps: I assume you are referring to mounts that worked before the server mount and not a case where the new mount was supposed to be exported.