From owner-freebsd-hackers  Wed May 29 01:37:24 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA18735
          for hackers-outgoing; Wed, 29 May 1996 01:37:24 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA18727
          for <hackers@freebsd.org>; Wed, 29 May 1996 01:37:12 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA27406; Wed, 29 May 1996 18:29:49 +1000
Date: Wed, 29 May 1996 18:29:49 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605290829.SAA27406@godzilla.zeta.org.au>
To: hackers@freebsd.org, jgreco@solaria.sol.net
Subject: Re: Breaking ffs - speed enhancement?
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I added a flag to mount to tell FFS not to worry about the datestamps on
>inodes.

>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.

Things like checking for mail actually depend on it.

Changes to atimes are written to the disk asynchronously, except for
utimes(2), so the bandwidth loss is not huge.  News file systems probably
lose more than most by thrashing the inode cache (another problem) so that
async inode writes are almost sync.  And perhaps something in your news
software uses utimes() a lot?  Once per (small) file creation is a lot.
You get one or two sync updates for the creat/write/close and one sync
update for utimes() - about 100% or 50% overhead.

I think atimes should be cached (or permanently allocated) independently
of their inodes.  It would be reasonable to cache a few hundred thousand
of them in memory.

>Am I just totally whacked out, or is this perhaps a reasonable thing to do,

Only for special file systems.

>(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).

You don't gain much by not changing the mtime/ctime.  They usually change
together with the file size and the file size must be written.

Bruce