From owner-freebsd-fs  Wed Jul 10 23:58:48 1996
Return-Path: owner-fs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA21481
          for fs-outgoing; Wed, 10 Jul 1996 23:58:48 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA21474;
          Wed, 10 Jul 1996 23:58:45 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id GAA10724; Thu, 11 Jul 1996 06:58:42 GMT
Date: Thu, 11 Jul 1996 15:58:42 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: dyson@FreeBSD.ORG
cc: freebsd-fs@FreeBSD.ORG
Subject: Re: Fixing Union_mounts
In-Reply-To: <199607110337.WAA07219@dyson.iquest.net>
Message-ID: <Pine.SV4.3.93.960711154052.10524B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Thanks, I guess it's bad timing with all the release work happening now.

On Wed, 10 Jul 1996, John S. Dyson wrote:

> I hope to look at this thread this weekend.  I know that we need to get
> off our duffs starting to make progress on the FS front.  My FreeBSD time
> is right now tied up on making the swapon/swapoff stuff real.
> 
> There is action about to happen on the Jeffery Hsu Lite-2 stuff, and
> I heard that Kirk's ordered-delay writes project might be starting.  This

Yes, the Lite2 stuff is needed to proceed further.

Regarding Delayed-Ordered Writes.  Here's an excerpt from Terry's Usenet
posting on the UnixWare group: 

>Contrast this with the UnixWare 2.x UFS, which uses Delayed
>Ordered Writes.  These require significant changes to each
>FS's structure to implement, and do not scale reeentrancy
>per vnode across multiple processors for a particular vnode
>buffer.  They are about 35% slower than soft updates under
>loading, and tend to have bad cache effects.

I agree that things should probably slow down, but to sit down and
do more *designing*.  DOW is an performance optimization, and before doing
that I think we should take a harder look at the framework that serves as
the foundation for all further work.

I'd hate to see the same mistakes done in SVR/4MP go into 4.4BSD.
Identifying these mistakes might be hard, but I think we should try.

-mike hancock