Hammer: Transactional file updates
dragonflybsd at wommm.nl
Fri Aug 1 09:12:53 PDT 2008
On Fri, 01 Aug 2008 17:36:13 +0200, Michael Neumann <mneumann at ntecs.de>
Jasse Jansson wrote:
On Aug 1, 2008, at 1:09 PM, Michael Neumann wrote:
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
close(fd); // behaves like COMMIT
That would be incredible cool (and very useful!) and could play well
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
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.
More information about the Users