Date: Thu, 27 Jan 2011 16:24: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: <20110127153956.J1436@besplex.bde.org> In-Reply-To: <4D408463.4000001@FreeBSD.org> References: <201101260506.p0Q56Bhf064034@svn.freebsd.org> <20110126173411.P972@besplex.bde.org> <4D408463.4000001@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Jan 2011, Doug Barton wrote: > On 01/25/2011 23:55, Bruce Evans wrote: >> ... >> 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 > ... > 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. > :) "The noatime option has no effect for nfs... BUGS: the noatime option should cause .Nm to fail, but it is turned into a no-op for bug for bug compatibility with historical behaviour." ? > 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? I can't see any in the source code. But I found a place where vfs examines the flag. I even wrote half of the original version of this (*). It is for marking atimes on exec and mmap. VOP_MARKATIME() is called if the vnode has a mount point and the flags for the mount point don't indicate noatime or readonly. But VOP_MARKATIME() is only implemented for ffs (even recent changes to reduce bitrot of ext2fs relative to ffs don't have it), and marking atimes on exec and mmap would be especially large foot-shooting for nfs, so this too has no effect for nfs (it just causes a null or bad vop to be called, and the result to be ignored. It is hard to see the exact default behaviour since even vfs_defaults.c doesn't have an explicit entry for vop_markatime). (*) The original version of this checked MNT_NOATIME and MNT_RDONLY in vfs only as an optimization. The rather heavyweight vop VOP_SETATTR() with was (ab)used,. Now there is a separate vop for this, and only 1 file system supports this, checking the MNT_* flags should be left to the file system. In practice, MNT_NOATIME and MNT_RDONLY are rarely set for file systems that support atimes, and MNT_NOATIME should never be set for a file system that doesn't support atimes, so checking them at the vfs level isn't even an optimization. We could use a mount flag that indicates that the file system doesn't support atimes at all, but this amounts to subverting the vop system -- non-support is properly indicated by the vop being null or bad. Or you can consider the flag as making the vop depend on the mount options (the file system instance) instead of only depending on the file system (the file system source code). That might be useful, but use of it should start with more interesting vops than VOP_MARKATIME(). Say VOP_WRITE() on readonly file system instances. Even that is a bit complicated, and vfs_mark_atime()'s check of MNT_RDONLY may have races, since the file system may and does in the case of ffs have a internal readonly flag that doesn't quite track MNT_RDONLY. As it happens, ffs has special, hackish handling of atimes on readonly file systems -- it marks them for update unconditionally, then cancels the marks at update time iff the file system instance is readonly at update time (maybe it now cancels them more correctly when the readonly flag(s) change). Thus it doesn't care about the MNT_RDONLY check that vfs_mark_atimes() does. But this doesn't work for VOP_WRITE(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110127153956.J1436>