From owner-freebsd-fs@FreeBSD.ORG Wed Jan 9 00:18:48 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F4AF60C for ; Wed, 9 Jan 2013 00:18:48 +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 ED69B737 for ; Wed, 9 Jan 2013 00:18:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKO27FCDaFvO/2dsb2JhbABEhjm3PHOCHgEBAQMBAQEBIAQnIAsFFg4KAgINBAEBEwIpAQkmBggHBAEcBIdwBgynMYJAjSSBIotLcwgBghmBEwOIYYp9gi6BHI8tgxKBTAcXHg X-IronPort-AV: E=Sophos;i="4.84,433,1355115600"; d="scan'208";a="11023281" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Jan 2013 19:18:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0C4B5B3EEA; Tue, 8 Jan 2013 19:18:41 -0500 (EST) Date: Tue, 8 Jan 2013 19:18:41 -0500 (EST) From: Rick Macklem To: Jason Keltz Message-ID: <972459831.1800222.1357690721032.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50EC39A8.3070108@cse.yorku.ca> Subject: Re: Problems Re-Starting mountd 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 Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 00:18:48 -0000 Jason Keltz wrote: > On 01/08/2013 10:05 AM, Andrey Simonenko wrote: > > I created 2000 file systems on ZFS file system backed by vnode md(4) > > device. The /etc/exports file contains 4000 entries like your > > example. > > > > On 9.1-STABLE mountd spends ~70 seconds in flushing current NFS > > exports > > in the NFS server, parsing data from /etc/exports and loading parsed > > data into the NFS server. ~70 seconds is not several minutes. Most > > of > > time mountd spends in nmount() system call in "zio->io_cv" lock. > > > > Can you show the output of "truss -fc -o /tmp/output.txt mountd" > > (wait wchan "select" state of mountd and terminate it by a signal). > > If everything is correct you should see N statfs() calls, N+M > > nmount() > > calls and something*N lstat() calls, where N is the number of > > /etc/exports > > lines, M is the number of mounted file systems. Number of lstat() > > calls > > depends on number of components in pathnames. > > Andrey, > > Would that still be an ~70 second period in which new mounts would not > be allowed? In the system I'm preparing, I'll have at least 4000 > entries > in /etc/exports, probably even more, so I know I'll be dealing with > the > same issue that Tim is dealing with when I get there. However, I don't > see how to avoid the issue ... If I want new users to be able to login > shortly after their account is created, and each user has a ZFS > filesystem as a home directory, then at least at some interval, after > adding a user to the system, I need to update the exports file on the > file server, and re-export everything. Yet, even a >1 minute delay > where users who are logging in won't get their home directory mounted > on > the system they are logging into - well, that's not so good... > accounts > can be added all the time and this would create random chaos. Isn't > there some way to make it so that when you re-export everything, the > existing exports are still served until the new exports are ready? I can't think of how you'd do everything without deleting the old stuff, but it would be possible to "add new entries". It has to be done by modifying mountd, since it keeps a tree in its address space that it uses for mount requests and the tree must be grown. I don't know about nfse, but you'd have to add this capability to mountd and, trust me, it's an ugly old piece of C code, so coming up with a patch might not be that easy. However, it might not be that bad, since the only difference from doing the full reload as it stands now would be to "not delete the tree that already exists in the utility and don't do the DELEXPORTS syscall" I think, so the old ones don't go away. There could be a file called something like /etc/exports.new for the new entries and a different signal (SIGUSR1??) to load these. (Then you'd add the new entries to /etc/exports as well for the next time mountd restarts, but wouldn't send it a SIGHUP.) I haven't tried to code this, so I don't know how hard it would be. If you did this, it would only be useful to add exports for file systems not already exported. > Would this be the same for NFSv3 versus NFSv4? I suspect yes. > Yep, the file system exports are done the same way. rick > Jason. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"