svn commit: r217871 - head/sbin/mount

[Garrett Cooper]

On Wed, Jan 26, 2011 at 12:30 PM, Doug Barton <dougb at freebsd.org> 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