From owner-freebsd-arch@FreeBSD.ORG Fri May 27 16:33:23 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3845816A41C for ; Fri, 27 May 2005 16:33:23 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D753743D1F for ; Fri, 27 May 2005 16:33:22 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j4RGXLsD000706; Fri, 27 May 2005 12:33:21 -0400 (EDT) From: Ken Smith To: Sergey Babkin In-Reply-To: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> Content-Type: text/plain Organization: U. Buffalo CSE Department Date: Fri, 27 May 2005 12:33:20 -0400 Message-Id: <1117211600.666.5.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Marc Olzheim , freebsd-arch@freebsd.org Subject: Re: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 16:33:23 -0000 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. > > 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. 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 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. Am I way off base? -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |