Hammer: Transactional file updates

Michael Neumann mneumann at ntecs.de
Fri Aug 1 09:24:04 PDT 2008


Martin Schut wrote:
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.
It shouldn't be default behaviour. One would have to specify:

  fd = open("file", O_TRANSACT);

If the application would crash, the file would be in the previous state.

Regards,

  Michael





More information about the Users mailing list