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? Message-ID: <Pine.BSF.3.91.960606003047.2129A-100000@kyklopen> In-Reply-To: <199606052046.NAA29627@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960606003047.2129A-100000>