> 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.