On Wed, Jan 17, 2001 at 06:24:28PM -0600, Ben Collins-Sussman wrote:
> Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
>
> Think of the filesystem like this: you have an array of "revisions",
> each revision pointing to a complete filesystem tree. These are
> immutable. Then you also have an array of "transactions"; these are
> filesystem trees as well, and contain pointers to existing nodes, but
> whereever there are changes, the node is a new "cloned" node. These
> transactions are temporary things; when a transaction is finished, the
> filesystem attempts to merge the transaction-tree into the newest
> revision-tree. If successful, a new revision tree is created. If
> there's a conflict, the whole transaction aborts and all of the cloned
> nodes are deleted. It never happened.
>
> So... now pretend you have two processes working on separate
> filesystem transactions. These two transactions both modify the same
> file. So yes, this file's node is now cloned *twice* in two different
> temporary trees.
>
> If process A successfully merges its transaction tree first, then
> process B's transaction will fail. Why? Because the filesystem's
> "merge" system is very intolerant: if you attempt to merge a cloned
> node into a node that is out-of-date, it bails. In this particular
> case, process A committed a new version of the node first, so process
> B's entire set of changes is going to be rejected when it tries to
> modify the same node.
>
Okay, that makes sense, thanks for the clear explanation.
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:19 2006