Preliminary Suggestion For Atomic Transactions

[Dag Wieers]

On Wed, 5 Jan 2005, Carson Gaspar wrote:

> --On Thursday, January 06, 2005 02:59:44 +0800 Jeff Pitman
> <symbiont at berlios.de> wrote:
> 
> > I give you .... (drum roll) ... atomic transactions ... (tada).  (Faces
> > with perplex looks go here.)
> 
> This is _not_ atomic. Please don't call it what it isn't. The only way I can
> think of to do an actual atomic update involves renaming the top level
> directory.

As you picked up correctly from the previous thread, it's not atomic, I 
called it near-atomic.

But it's a trade-off between not having to hardlink a whole lot of files 
(in my case 300.000 files for each transaction), making it possible to 
sync with more then one client, not having to configure a directory and 
having it inside rsync (which could work both ways and does not require a 
wrapper).

Currently the time my repository is out-of-sync for the time the 
transaction takes (often 30mins to 4 hours) based on size and bandwidth. 
(In between I have to prevent mirrors from updating or live with the 
consequences until the next sync, my mirrors have the same problems 
btw...) This change will make it out-of-sync only for the time it takes to 
rename a number of files (often between 20 to 100) which is in the 
seconds, I hope.

Maybe it would be nice to also have your atomic implementation in rsync 
and people can choose what algorithm to use. Both make sense in different 
cases, I'm sure.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]