From owner-freebsd-hackers  Fri May 31 14:53:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA23743
          for hackers-outgoing; Fri, 31 May 1996 14:53:58 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA23729
          for <hackers@freebsd.org>; Fri, 31 May 1996 14:53:56 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18849; Fri, 31 May 1996 14:49:30 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199605312149.OAA18849@phaeton.artisoft.com>
Subject: Re: Breaking ffs - speed enhancement?
To: bde@zeta.org.au (Bruce Evans)
Date: Fri, 31 May 1996 14:49:30 -0700 (MST)
Cc: rashid@rk.ios.com, terry@lambert.org, davidg@Root.COM, hackers@freebsd.org,
        jgreco@solaria.sol.net
In-Reply-To: <199605301011.UAA14948@godzilla.zeta.org.au> from "Bruce Evans" at May 30, 96 08:11:19 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >There is a school of thought that says "shall be updated" in POSIX is
> >not the same as "shall be committed to stable storage" (the traditional
> >BSD implementation).
> 
> When was this traditional?

It's just historical behaviour; has to do (in 4.3) with whether or
not O_ASYNC is set or not.  The write is done, regardless; it *will*
be happening, not as a result of LRU.  The only remaining question
is "how soon", which bears on how much gathering will effectively
take place on multiple references.  The bigger the FS, the sparser
the outcome.

> >This would let access times be updated in core, but only scheduled to
> >be written at a later time (not forced out immediately).
> 
> 4.4BSD and I think Net/2 always only scheduled them to be written at a
> later time.  At the end of every read (incorrectly including unsuccessful
> ones), access times are marked for update:
> 
> 	ip->i_flag |= IN_ACCESS;	/* see ufs_readwrite.c */
> 
> At certain checkpoints, the access times are updated.  E.g., in ufs_close()
> 
> 	if (inuse && !locked)
> 		ITIMES(ip, &time, &time);
> 
> If IN_ACCESS is set, this sets the access time in-core, sets IN_MODIFIED, and
> clears IN_ACCESS.  It doesn't write the inode.  Setting IN_MODIFIED schedules
> the inode to be written on the next sync, or when it is reused.  ffs_sync()
> calls VOP_UPDATE() with the sync-update flag clear and ffs_update() schedules
> a delayed write.

The thing should be updated when it is LRU'ed out of cache, not when it
is synced.  But since the cache is vnode data-block based in its use
of LRU's, this can't happen.  All non-data-block FS data gets committed
an average of 30 seconds after it is changed (the sync interval).

metadata of any kind is a second class citizen in vnode/offset based
block cacheing.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.