TransactionalFS (Was: Re: bzr too slow)

[Jan Hudec]

On Thu, Jan 12, 2006 at 10:15:32 +0100, Denys Duchier wrote:
> Jan Hudec <bulb at ucw.cz> writes:
> 
> > On Thu, Jan 12, 2006 at 02:24:42 +0100, Denys Duchier wrote:
> >> 
> >> My own approach to this issue is basically the TransactionFS that I posted about
> >> earlier.
> >
> > Can you please point me to that earlier post? I don't can't find it here
> > and the archive does not seem to support searching.
> 
> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/6859

Thanks,

I have checked it out
(http://delta.univ-orleans.fr/~duchier/bzr/TransactionFS/) and looked
around. Well, it does not actually do transactions, unfortunately.

Now there I know of a way to do transactions. Unfortunately it:
- Requires a POSIX filesystem with:
	- POSIX rename (atomically replacing)
	- Symlinks
	- Hardlinks
	- Copying full contents of modified files.
- If it should do other operations than just writing atomically, the
  directory actually has to be accessed via symlink (because you can't
  atomically replace directory).
In return, it is atomic against unaware reader and should be possible to
forcibly roll back safely. It is implemented by the
File::Transaction::Atomic Perl module (see CPAN).
It is pretty complex, requiring chained symlinks and other weirdness.
Note, that I believe it would work over POSIX compliant network
filesystem just as well.

Bzr does not need all that complexity though, because it can choose
layout and read in a careful order to avoid incomplete data.

Generally if it was possible to do locking - such that would break when
connection breaks - transactions would be pretty simple. If you can take
the lock, the other client is dead, so look at what it last did and
either roll it back or complete it. However, ftp can't do locks and sftp
can, but I am not sure how many servers actually support it. So the
question actually is how to do reliable locking -- one that either can't
be broken while the client is alive (I doubt that it's possible) or one
that when broken prevents the client to screw things up any further.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060112/3ed326dd/attachment.pgp