[PATCH 1 of 6] transaction: ensure journal is committed to file system

[Matt Mackall]

On Thu, 2009-04-23 at 09:40 +0200, Henrik Stuart wrote:
> Matt Mackall wrote:
> > On Wed, 2009-04-22 at 09:07 +0200, Henrik Stuart wrote:
> >> Matt Mackall wrote:
> 
> [snip]
> 
> >>> If you're so inclined, we can add a companion to the journal that stores
> >>> just that revision number and gets synced at the beginning of a
> >>> transaction. Then we can add a slow path in recover that strips to that
> >>> revision.
> >> I propose that, if the general fsync isn't preferable, we add a flush
> >> method transaction that may be optionally called by whomever is using
> >> the transaction. That way strip can set up the entire transaction, call
> >> fsync, committing it to disk, and then proceeding merrily with a
> >> recoverably repository. It doesn't, of course, do anything for normal
> >> revlog writing, but it won't be worse for those than it is today. I'll
> >> send the entire patch series in a revised version in a bit.
> > 
> > Sure. Though I'm not sure why you don't like my revision number
> > suggestion. It has the added benefit that we can say "rollback will take
> > you back to revision x".
> 
> I'm not adverse to the revision number suggestion at all, and I think it
> would be nice if that was done eventually. I just don't have the time to
> write that right now.
> 
> So, to get back to the patches at hand, is the stance that the patch
> using flush() isn't acceptable and should be left out? (This will also
> require a minor change to patch 6, of course).

I assume you mean fsync()? Yes, I'd rather not go that way.

-- 
http://selenic.com : development and support for Mercurial and Linux