DragonFly users List (threaded) for 2008-08
DragonFly BSD
DragonFly users List (threaded) for 2008-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Hammer: Transactional file updates

From: "Martin Schut" <dragonflybsd@xxxxxxxx>
Date: Fri, 01 Aug 2008 18:12:53 +0200

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

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
  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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]