From owner-freebsd-hackers  Wed Jun  5 16:45:50 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA17864
          for hackers-outgoing; Wed, 5 Jun 1996 16:45:50 -0700 (PDT)
Received: from uucp.DK.net (uucp@uucp.DK.net [193.88.44.47])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA17853;
          Wed, 5 Jun 1996 16:45:46 -0700 (PDT)
Received: from pingnet (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id BAA03433; Thu, 6 Jun 1996 01:44:26 +0200
Received: from kyklopen by ic1.ic.dk with UUCP id AA22098
  (5.65c8/IDA-1.4.4j); Thu, 6 Jun 1996 01:12:57 +0200
Received: (from staff@localhost) by kyklopen.ping.dk (8.7.5/8.7.3) id AAA02946; Thu, 6 Jun 1996 00:57:39 +0200 (MET DST)
Date: Thu, 6 Jun 1996 00:57:37 +0200 (MET DST)
From: Thomas Sparrevohn <staff@kyklopen.ping.dk>
To: Terry Lambert <terry@lambert.org>
Cc: dyson@FreeBSD.ORG, jehamby@lightside.com, terry@lambert.org,
        bde@zeta.org.au, dufault@hda, hackers@FreeBSD.ORG
Subject: Re: Breaking ffs - speed enhancement?
In-Reply-To: <199606052046.NAA29627@phaeton.artisoft.com>
Message-Id: <Pine.BSF.3.91.960606003047.2129A-100000@kyklopen>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Charset: ISO_8859-1
X-Char-Esc: 29
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 5 Jun 1996, Terry Lambert wrote:

[snap]

> 
> I'm personally now less interested in LFS than I am in soft updates,
> and more in the direction of a general graph theory soloution to FS's
> as a set of event nodes, and consistency guarantees as a set of event
> handling ording rules with soft updates implemented as an inter-node
> conflict resoloution schema.
> 

I don't  see any conflict there. The right thing to do would be
to redo the Vfs/Vnode according to soft-updates. But could'nt the
two things be combined? The approach suggested by Ganger and Patt
could be applied to LFS in the directory handling code that expects
some kind of write ordering anyhow.

[snip]

> 
> How complex do you view this to be?  I believe that most of the LFS
> single file/directory problems with a catastrophic failure can be
> handled on mount by rolling transaction back (rolling them forward
> would require journalling, not just log-structuring).
>

Yes that is one of the major problems. You can only expect the roll forward
in LFS to handle segment inconsistency not structural inconsistency.

> One of the problems I have with LFS in this regard that I *wouldn't*
> have with an event-based soft updates implementation is implied
> state tracking across multiple FS objects.  One example of this would
> be a dBase III database file with an index file.  When the database
> changes, the index needs to change as well, iempotently.  This is
> handleable for dBase III by rebuilding the index, but a true relational
> database implementation could not be so easily fixed.

I don't think that the FS layer has to have anything to do with event
graphs. I think it should be possible to have the VFS/Vnode layer handle 
that kind of dependency.

> 
> A soft udates implementation would allow you to impose event dependency
> on the graph for multi-object transactions (assuming multi-object
> ordering enforcement, like for an LFS log that won't overwrite for
> two seperate events in the same transaction).
> 

Would'nt that be the same as a general transaction based VFS?

Regards
  Thomas