From owner-svn-src-all@FreeBSD.ORG Fri Jan 28 09:06:31 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 28E42106566C; Fri, 28 Jan 2011 09:06:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id B5FE48FC0C; Fri, 28 Jan 2011 09:06:30 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0S96Q5s027886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 20:06:28 +1100 Date: Fri, 28 Jan 2011 20:06:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Doug Barton In-Reply-To: <4D41D52D.2080906@FreeBSD.org> Message-ID: <20110128194615.G1167@besplex.bde.org> References: <201101260506.p0Q56Bhf064034@svn.freebsd.org> <20110126173411.P972@besplex.bde.org> <4D408463.4000001@FreeBSD.org> <20110127153956.J1436@besplex.bde.org> <4D41D52D.2080906@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Fri, 28 Jan 2011 09:06:31 -0000 On Thu, 27 Jan 2011, Doug Barton wrote: > On 01/26/2011 21:24, Bruce Evans wrote: >> On Wed, 26 Jan 2011, Doug Barton wrote: > >>> 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. :) >> >> What is the effect? > > Um, the expected one? :) > > If I use a FreeBSD client to nfs mount something on a solaris system with the > noatime option then the access time does not change no matter how many times > I access the file. If I then unmount and remount without the noatime option > the access time will be modified. If I do the same thing but with a FreeBSD > nfs server the access time is modified, with or without the noatime option. The solaris server behaviour can't happen, except accidentally due to races :-). Since the FreeBSD client doesn't support the noatime flag except to ignore it, it can't tell any server about it. The FreeBSD server behaviour is as expected -- unmounting flushes the client's cache, so the first read after remounting goes to the server and the server must mark the atime for update (unless the server filesystem is mounted with noatime); then a later stat() on the client should somehow see an updated atime (but I wonder if caching defeats this too -- stat() on the server must change any mark for update to an update, but the client has an attribute cache which should be used to prevent most stat()s going to the server). Bruce