From owner-freebsd-hackers  Tue Jul 30 14:28:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA08439
          for hackers-outgoing; Tue, 30 Jul 1996 14:28:39 -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 OAA08412;
          Tue, 30 Jul 1996 14:28:07 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA00658; Tue, 30 Jul 1996 14:26:47 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199607302126.OAA00658@phaeton.artisoft.com>
Subject: Re: Union mounts and other mounts
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Tue, 30 Jul 1996 14:26:47 -0700 (MST)
Cc: toor@dyson.iquest.net, michaelh@cet.co.jp, freebsd-fs@FreeBSD.ORG,
        freebsd-hackers@FreeBSD.ORG
In-Reply-To: <1028.838313231@critter.tfs.com> from "Poul-Henning Kamp" at Jul 25, 96 06:47:11 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

> Jeff's changes have higher priority for me than Terrys, because they
> bring us closer to the codebase Kirk is hacking away on, and he has
> some nice things brewing too.

Yes; I was under the impression that one of the things Kirk was doing
was soft updates.  Matt Day already has an FFS integration of soft
updates against the FreeBSD FS code, as ported to Windows 95.

I dislike the idea of seperately retrofitting each FS code base (in
the BSD case, it means seperate UFS chunks for FFS and LFS and ...
unless Kirk is retrofitting all of the FS's.

Finding out where soft updates go in a given FS is a graph reduction
problem.  The way Ganger and Patt solved the problem hides the
graph reduction, and so is very FFS specific.  I think this is a
design error, but it was expedient, since you would otherwise have
to consider each FS as a set of event points in an acyclic graph
of event dependencies mixed in with POSIX semantics.  Considering
FS's as event/trigger/processing sets is not really an easy thing,
given how the code is arranged.

Eventually, I'd like to see the FS defined in terms of events and
reactions to events.  With an up-front graph, you could establish
a node/callback chain when the FS is instantiated, and then do I/O
in the context of event nodes.  This would let you have a single
engine for doing soft updates, which is referenced by all FS's, instead
of having to hack the soft updates into each FS on a case-by-case
basis.


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