From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 22:16:19 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED979106564A; Wed, 26 Jan 2011 22:16:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3908FC12; Wed, 26 Jan 2011 22:16:18 +0000 (UTC) Received: by wwf26 with SMTP id 26so1386027wwf.31 for ; Wed, 26 Jan 2011 14:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/KEjwLHP0uUiDPK7uIKO0Q9nF3DX+nXMNDASK4RF17U=; b=gnrx8mGzqdO8APLeIR2sfGE7eAkPLVo6mLbqslpgdifRopDimJ9PEtXW4+EPRuOprs Kf5nxDvW/6+Ewx2GXHFa81hAyzeXpyqfkGF+TRVV0VSJrivuUwmHm9ExF3G/Q8HL1wwX q7MvrN4DilF/RpJI+TRRZFjBzTM5zkHE4L9yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SKvdFxvRbjO7+CtDleuwkioEBE8RZTvB09j6NeS96ecFQzvVqk8RKRzSTLsmTRpQis zqRvzjvBr4PDDyiu9ZNmUe0td4cmdAITPINu218DeSdEw6ZCRj0Dmw2U5oRXlX/C6Q4y 1R7b7jZ527Ysqv92/ZISj2RgwZOz0Sbbn4fZQ= MIME-Version: 1.0 Received: by 10.216.30.137 with SMTP id k9mr1042881wea.31.1296080177658; Wed, 26 Jan 2011 14:16:17 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Wed, 26 Jan 2011 14:16:17 -0800 (PST) In-Reply-To: <4D408463.4000001@FreeBSD.org> References: <201101260506.p0Q56Bhf064034@svn.freebsd.org> <20110126173411.P972@besplex.bde.org> <4D408463.4000001@FreeBSD.org> Date: Wed, 26 Jan 2011 14:16:17 -0800 X-Google-Sender-Auth: RZmgBme1_jfQ4koROqIKLLWQ0AE Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans Subject: Re: svn commit: r217871 - head/sbin/mount X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 22:16:20 -0000 On Wed, Jan 26, 2011 at 12:30 PM, Doug Barton wrote: > On 01/25/2011 23:55, Bruce Evans wrote: >> >> On Wed, 26 Jan 2011, Doug Barton wrote: >> >>> Log: >>> Clarify the availability of the noatime option on network file systems >>> >>> Modified: >>> head/sbin/mount/mount.8 >>> >>> Modified: head/sbin/mount/mount.8 >>> >>> ============================================================================== >>> >>> --- head/sbin/mount/mount.8 Wed Jan 26 01:07:56 2011 (r217870) >>> +++ head/sbin/mount/mount.8 Wed Jan 26 05:06:11 2011 (r217871) >>> @@ -28,7 +28,7 @@ >>> .\" @(#)mount.8 8.8 (Berkeley) 6/16/94 >>> .\" $FreeBSD$ >>> .\" >>> -.Dd February 10, 2010 >>> +.Dd January 25, 2011 >>> .Dt MOUNT 8 >>> .Os >>> .Sh NAME >>> @@ -208,7 +208,11 @@ This option >>> is useful on file systems where there are large numbers of files and >>> performance is more critical than updating the file access time (which is >>> rarely ever important). >>> -This option is currently only supported on local file systems. >>> +This option is not supported on network file systems when the >>> +server is FreeBSD. >>> +Support in network files servers on other operating systems >>> +with a FreeBSD client is possible, >>> +but should be tested before it is relied on. >> >> Even atimes are not supported by at least the non-experimental FreeBSD >> client, so attempts to turn them off are nonsense and should have >> always failed at mount time. But such attempts bogusly always succeed >> and have no effect, even if atimes are otherwise supported, since: >> - for mount(2), the nonstandard option MOPT_NOATIME has always been >> bogusly in the standard options list MOPT_STDOPTS. Thus it is was >> never rejected by mount_nfs(8) or for other mount utilities than >> use mount(2), even for file systems for fies that don't even have atimes. >> - for nmount(2) in both the non-experimental and experimental cilent >> the unsupported option "noatime" is bogusly in the supported options >> list together with lots of other unsupported options like "suiddir", >> "nocluster[rw]", "multilabel" and "acls". All of these nonstandard >> options are also bogusly in MOPT_STDOPTS. >> - bogusly setting the MNT_ATIME flag in an attempt to turn off atime has >> no effect in any FreeBSD nfs client, since the MNT_ATIME flag is never >> referenced. And, at least in the non-experimental client, since even >> atimes are not supported, there is nothing useful that references to >> MNT_ATIME could do. >> >> Non-support of atimes by by at least the old FreeBSD client: Most >> reads are from the nfs cache (else most reads would be very slow). >> Since the client doesn't support atimes, it doesn't do the fancy caching >> of them that would be needed to make them sort of work without defeating >> the cache by telling the server about every read. So atimes just get >> updated on the server when the server is asked to fill the cache, and >> then only if the server supports atimes (not counting when an application >> on the client explicitly sets them using utimes(2). Full support for >> noatime/noatime on the client would involve negotating it with the >> server, so that the client's noatime flag has preference over the >> server flag on files read by that client... AFAIK there is no way to >> negotiate this. Client caching of atimes might also need delicate >> negotiation depending on how POSIXly you want atimes to work. >> >> I sometimes think that atimes should be handled mostly in vfs. The >> MNT_ATIME could then have an effect without any references to it in >> file systems that sort of support atimes, but ones that don't even >> have atimes should still make vfs reject attempts to use it. > > I think I understand most, if not all of what you wrote here, but I'm not > nearly smart enough to translate it into something succinct for the man > page. :) > > My concern was that the man page says that we don't support the option at > all, but with a FreeBSD client and a solaris server it has a demonstrable > effect. If someone wants to improve the wording then by all means, either > make a suggestion or just do it. :) Maybe something should just be added to the BUGS section for this item? Thanks, -Garrett