Re: Hammer: Transactional file updates

["Martin Schut" <dragonflybsd@xxxxxxxx>]

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