Hammer: Transactional file updates

[Martin Schut]

On Fri, 01 Aug 2008 17:36:13 +0200, Michael Neumann <mneumann at ntecs.de>  
wrote:

Jasse Jansson wrote:
 On Aug 1, 2008, at 1:09 PM, Michael Neumann wrote:

Hi,

So Hammer does not guarantee "transctional consistency" of data in case
of a crash, only that of meta-data, right?
Is there a method to guarantee the write to be transactional, so that
I either have the previous "version" of the file or the version that I
wrote? Like this:
  fd = open(file);  // behaves like START TRANSACTION
  read(fd, ...);
  write(fd, ...);
  close(fd);        // behaves like COMMIT
That would be incredible cool (and very useful!) and could play well  
due
to Hammers historical nature.
 You are talking about COW (copy on write), right.
It slows things down, but it's cool.
Well, Hammer's history-retention IMHO is similar, just that it is less
fine-grained than COW.
I'm not sure how Hammer internally works, but I think that a single
write() can generate a new version of that file (at least if you wait 30
seconds). What I'd like to have is the ability to do multiple writes to
that file and once I reach the end of my write transaction switch the
file to use that new version. During that period of time, other readers
would see the old content. Basically like a transaction in a database,
but provided by Hammer so that I don't have to reimplement transactions
myself ;-).
Sounds cool, however what to do once a application crashes. I suppose you  
will not commit. But then, a lot of log-files are not written at all. Also  
utils like tail -f won't work to.

Regards,

Martin