Date: Fri, 28 Jan 2011 20:06:26 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Doug Barton <dougb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r217871 - head/sbin/mount Message-ID: <20110128194615.G1167@besplex.bde.org> In-Reply-To: <4D41D52D.2080906@FreeBSD.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110128194615.G1167>