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/

_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to