Date: Sat, 28 May 2005 14:51:43 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: Marc Olzheim <marcolz@stack.nl>, Sergey Babkin <babkin@verizon.net>, freebsd-arch@FreeBSD.org Subject: Re: Re: Modifying file access time upon exec... Message-ID: <20050528141302.J81578@delplex.bde.org> In-Reply-To: <1117211600.666.5.camel@opus.cse.buffalo.edu> References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 May 2005, Ken Smith wrote: > On Fri, 2005-05-27 at 11:12 -0500, Sergey Babkin wrote: >>> No, I'm saying that there are filesystems you wouldn't want to mount >>> with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some >>> software depends on the atime being adjusted. >>> >>> But atime over NFS is something you'd usually want to turn off, because >>> it can really hurt performance. Except it cannot really be turned off. It can be turned off on the server but that setting is wrong if some clients really want it on. It cannot be turned off on clients (the mount flag for it has no effect). FreeBSD only has broken clients which mostly don't set it as necessary, so it is normally sort of mostly off by default. If the clients weren't broken then there would be a lot of nfs traffic to sync it. See another reply for more details. >> As a compromise, would it make sense to make the >> atime granularity adjustable? I.e. instead of the >> default microsecond granularity use a 1-second >> granularity. Or a 10-second granularity, so that the >> atime would be adjusted only once per every 10 >> seconds. And similarly for mtime, though here >> you should obviously be more careful. The default granularity for ffs is already much larger than 1 second. The precision is 1 second, but atimes are normally not changed even in memory (they are only marked for update) until many seconds after the even that marked them, when one of the following events occurs: - someone looks at the times using stat(2) or friends - the file is (last-?) closed - the file is synced Even with this, actual updates of atimes can be ridiculously expensive in some (not so usual) case. You can have a few million files cached in few GB of memory. No disk accesses need occur to read() or exec() these files. But then if somone looks at all the files using something like a recursive grep, you have to do millions of writes to sync 8-16 bytes of atime info for each file. 8-16 * millions of bytes might not take long to write, but they do if they are done sparsely in millions of separate writes. I think the right way to implement atimes is to use a contiguous are of disk for them and never sync them until unmount() or memory for them runs out. OTOH, exec()ing millions of different files in a short time seems unlikely. For exec(), the case to worry about is exec()ing the same file repeatedly. The mark-for-update method works well for this in local file systems. Unfortunately, simple implementations of it cannot work for remote file systems. Someone might stat() the file on another client... The 10-second granularity might be useful here. stat() on the other client would still need to sync with local caches/marks for update on other clients, but the other clients and the server can know that there is no need to sync if less than 10 seconds has elapsed since the last tick of the 1/10 Hz clock that gives the time to possibly update (this clock must be synchronized). This wouldn't work for mtimes. The granularity must be much less than 10 seconds for make(1) to work. I'm surprised it mostly works with a granularity of 1 second. > I'm still a tiny bit confused but that's probably just me. Normally > when setting up an environment with diskless clients in it I set things > up so that the portions of the server containing executable files are > mounted read-only on all the clients. I typically can't trust the > client machines enough to grant them write access to something > like /usr. So, in that sort of an environment this is a non-issue. As Yes, this should prevent the client wasting the server's and its own time. > mentioned above there are portions of the environment you can't do that > for but none of those directories mentioned above would contain > executable files. And the places that do contain executable files > (e.g. /usr) are mounted read-only. So there should be no noticable > impact from the proposed patch if that sort of setup is normal. I use non-diskless clients with /usr nfs-mounted, not readonly and sometimes written to, so the client should be asking for atime updates (since it doesn't understand -noatime), but I use -noatime on all local file systems so atimes are effectively off since -noatime works on the server. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050528141302.J81578>