Date: Wed, 26 Jan 2011 12:30:27 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r217871 - head/sbin/mount Message-ID: <4D408463.4000001@FreeBSD.org> In-Reply-To: <20110126173411.P972@besplex.bde.org> References: <201101260506.p0Q56Bhf064034@svn.freebsd.org> <20110126173411.P972@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D408463.4000001>