Date: Tue, 1 Oct 1996 12:18:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: kpneal@pobox.com, greywolf@siva.captech.com, hackers@FreeBSD.ORG, tech@openbsd.org, current-users@NetBSD.ORG Subject: Re: VPS mailing list, BSD interest? Message-ID: <199610011918.MAA02275@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.961001134913.22919C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 1, 96 01:55:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> In practice it's very difficult to design and implement stackable vnodes > correctly, though I'm optimistic someone will rise to the challenge. In practice, a file system is not a database. A file system is a set of events and actions. There is a dependency graph for action ordering. If you consider the file system in terms of this graph, there are node relationships with commutative and associative properties. Soft updates, as implemented in FFS by Ganger/Patt, takes specific advantage of the commutative and associative propertives of these node updates, for FFS *only*, and imposes queue ordering semantics on scheduling of actions. The Ganger/Patt work is a specific soloution to a problem that is a member of a more general problem set (this is why it is a mistake to pursue soft updates for only one FS implementation, like Keith is currently doing. Unfortunately, I haven't had a lot of time to try and get a hold of him about the problem). If you consider all FS's in this light, then what you end up with is: 1) a graph 2) a list of relationships between nodes in the graph 3) a finite state automaton model for node conflict resoloution This leads to the design of a FS independent soft update mechanism that operates by: 1) when the FS is instantiated, the node relationship is registered and callback routines for action handling are registered to handle events 2) at the same time, callback routines for conflict resoloution suring commutation and association operations are registered So you end up with a defined "bottom layer" that is used by all FS's which which to communicate with storage media, and you interpose this layer between the FS and the VM system. For stacking, you can imply an action queue flush as a default mechanism fro resolving conflict. Ideally, you would provide conflict resoloution inter-FS layer. I think the difficulty you see is exagerated by looking at the problem from the traditional FS design perspective. Most of the issues that are apparent from that perspective fall out when you look at it from another angle. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610011918.MAA02275>