From owner-freebsd-hackers  Wed May 29 02:11:10 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA20715
          for hackers-outgoing; Wed, 29 May 1996 02:11:10 -0700 (PDT)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA20709
          for <hackers@freebsd.org>; Wed, 29 May 1996 02:11:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id CAA01059; Wed, 29 May 1996 02:11:06 -0700 (PDT)
Message-Id: <199605290911.CAA01059@Root.COM>
X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol
To: Joe Greco <jgreco@solaria.sol.net>
cc: hackers@freebsd.org
Subject: Re: Breaking ffs - speed enhancement? 
In-reply-to: Your message of "Tue, 28 May 1996 23:04:11 CDT."
             <199605290404.XAA25324@solaria.sol.net> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Wed, 29 May 1996 02:11:06 -0700
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Intended goal: on a busy news server with a hundred articles per second
>going out the door, I felt that it might not be reasonable to try to write
>the st_atime changes back out to the disk.  Basically, no one gives a rip,
>and that's a lotta writes that I don't have time or disk bandwidth to do.
...
>Am I just totally whacked out, or is this perhaps a reasonable thing to do,
>given that I'd really rather not have to absorb the extra write activity on
>the filesystems...  does anybody else perceive any value along these lines
>of thought?

   You're not totally whacked out. I attempted to implement the same thing
here, but got stuck with the flag still getting set somewhere/sometimes and
had to drop that work for more important things.

>(I don't pretend to think my patches are complete or correct, btw, I just
>wanted to see how badly I could mess things up.  In particular due to the
>way I did things, file dates don't get set on a create, either, so all my
>files are dated 1969.  The "ideal" solution might set the date correctly on
>a create, but not touch it on a modify or a read).

   I added an option "noatime" to mount/fstab and implemented a special
per-mount flag for this in the kernel. I was only interested in disabling
the access time; I wanted the inode change time and modify times to still
work correctly. My application, of course, was wcarchive - a machine with
millions of files that spends about 1/3-1/2 of all of it's disk I/O just
updating the access times in the inodes.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project