From owner-freebsd-fs@FreeBSD.ORG Wed Jan 9 18:36:46 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 3F84983A for ; Wed, 9 Jan 2013 18:36:46 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id 0D17B3FF for ; Wed, 9 Jan 2013 18:36:46 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tt0Vz-0008Vl-Bb; Wed, 09 Jan 2013 13:36:39 -0500 Message-ID: <50EDB8B7.4040708@cse.yorku.ca> Date: Wed, 09 Jan 2013 13:36:39 -0500 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrey Simonenko Subject: Re: Problems Re-Starting mountd References: <20130103123730.GA19137@pm513-1.comsys.ntu-kpi.kiev.ua> <20130108150508.GA2248@pm513-1.comsys.ntu-kpi.kiev.ua> <50EC39A8.3070108@cse.yorku.ca> <20130109125554.GA1574@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20130109125554.GA1574@pm513-1.comsys.ntu-kpi.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: On 01/09/2013 07:55 AM, Andrey Simonenko wrote: > > When mountd starts it flushes NFS export settings for all file systems, > for each mount point it calls nmount(), even if /etc/exports is empty > it will call nmount() for all currently mounted file systems. > > When mountd loads export settings into NFS server it calls statfs() and > lstat() for each pathname from /etc/exports (number of lstat() calls depends > on number of '/' in each pathname), then it calls nmount() for each > address specification for each pathname from /etc/exports. It uses > nmount() interface for communication with kern/vfs_export.c that is > responsible for NFS export settings for file systems. For the NFSv4 > root directory mountd uses nfssvc() to update its settings, that > calls kern/vfs_export.c:vfs_export(). > > When mountd receives SIGHUP it flushes everything and loads /etc/exports. > This signal is sent by mount(8) when it mounts any file system. > > This delay in above described example came from ZFS kernel code, since > the same configuration for 2000 nullfs(5) file systems takes ~0.20 second > (less than second) by mountd in nmount() system calls. At least on > 9.1-STABLE I do not see that this delay came from mountd code, it came > from nmount() used by mountd. > [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 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 18:36:46 -0000 On 01/09/2013 07:55 AM, Andrey Simonenko wrote: > > When mountd starts it flushes NFS export settings for all file systems, > for each mount point it calls nmount(), even if /etc/exports is empty > it will call nmount() for all currently mounted file systems. > > When mountd loads export settings into NFS server it calls statfs() and > lstat() for each pathname from /etc/exports (number of lstat() calls depends > on number of '/' in each pathname), then it calls nmount() for each > address specification for each pathname from /etc/exports. It uses > nmount() interface for communication with kern/vfs_export.c that is > responsible for NFS export settings for file systems. For the NFSv4 > root directory mountd uses nfssvc() to update its settings, that > calls kern/vfs_export.c:vfs_export(). > > When mountd receives SIGHUP it flushes everything and loads /etc/exports. > This signal is sent by mount(8) when it mounts any file system. > > This delay in above described example came from ZFS kernel code, since > the same configuration for 2000 nullfs(5) file systems takes ~0.20 second > (less than second) by mountd in nmount() system calls. At least on > 9.1-STABLE I do not see that this delay came from mountd code, it came > from nmount() used by mountd. > Hi Andrey, Thanks for your message. If this is the case, I wonder if there's really any change that needed at all. Maybe one of the ZFS filesystem maintainers might have some idea why 2000 nullfs filesystems take ~0.20 second to process with nmount(), yet the same number of ZFS filesystems take so much longer to process. Maybe there's a bug somewhere? Jason.