Re: filesystem transactions API

[Lars Marowsky-Bree <lmb@suse.de>]

On 2005-04-26T11:40:02, "Charles P. Wright" <cwright@cs.sunysb.edu> wrote:

> Atomicity is difficult, because you have lots of caches each with their
> own bits of state (e.g., the inode/dentry caches).  Assuming your
> transaction is committed that isn't so much of a problem, but once you
> have on rollback you need to undo any changes to those caches.
> 
> Isolation (this is the property that says that concurrent transactions
> should be the same as if there was a serial execution) is also tricky to
> get right.  A transaction can touch any number of objects, and user-
> applications may not respect any lock ordering --- which means you will
> have deadlocks, and you must detect and resolve them (probably by
> aborting one of the transactions).

Just as a weird idea, spawned by the FUSE thread.

"Transactions happen in their own namespace".

Besides having a namespace_(create|join) as needed for FUSE (or
similar), there'd be a privileged namespace_replace(target, source) (or
_merge, if you prefer - that however seems to imply that a namespace was
actually forked off another).

So, you want transactions for testing some software update, you create
your new one, mount stuff, do the update, and then "commit" it by
replacing the global namespace by it.

If you want to discard, just exit it. As soon as no further references
to a namespace exist, it can be cleaned up (and non-persistent
transactions will be 'unrolled' and thrown away).

Now where's that pipe of mine... ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business