git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v4 0/3] Make update refs more atomic

From
Ronnie Sahlberg <sahlberg@google.com>
Date
Apr 14, 2014, 18:29 UTC
Message-ID
<1397500163-7617-1-git-send-email-sahlberg@google.com>

refs.c:ref_transaction_commit() intermingles doing updates and checks with actually applying changes to the refs in loops that abort on error. This is done one ref at a time and means that if an error is detected that will fail the operation partway through the list of refs to update we will end up with some changes applied to disk and others not.

Without having transaction support from the filesystem, it is hard to make an update that involves multiple refs to guarantee atomicity, but we can do a somewhat better than we currently do.

These patches change the update and delete functions to use a three call pattern of

1, lock 2, update, or flag for deletion 3, apply on disk (rename() or unlink())

When a transaction is commited we first do all the locking, preparations and most of the error checking before we actually start applying any changes to the filesystem store.

This means that more of the error cases that will fail the commit will trigger before we start doing any changes to the actual files.

This should make the changes of refs in refs_transaction_commit slightly more atomic.

Version 4:
* Fix a bug in fast-import.c:dump_tags and make sure no tests fail
Version 3:
* Rebased onto mhagger/ref-transactions.
* Removed the patch to do update/delete from a single loop.
Version 2:
Updates and fixes based on Junio's feedback.
* Fix the subject line for patches so they comply with the project standard.
* Redo the update/delete loops so that we maintain the correct order of
  operations. Perform all updates first, then perform the deletes.
* Add an additional patch that allows us to do the update/delete in the correct
  order from within a single loop by first sorting the refs so that deletes
  are after all non-deletes.
Ronnie Sahlberg (3):
  refs.c: split writing and commiting a ref into two separate functions
  refs.c: split delete_ref_loose() into a separate flag-for-deletion and
    commit phase
  refs.c: change ref_transaction_commit to run the commit loops once all
    work is finished
 branch.c               | 10 ++++--
 builtin/commit.c       |  5 +++
 builtin/fetch.c        |  7 +++-
 builtin/receive-pack.c |  4 +++
 builtin/replace.c      |  6 +++-
 builtin/tag.c          |  6 +++-
 fast-import.c          | 18 ++++++++--
 refs.c                 | 98 +++++++++++++++++++++++++++++++++-----------------
 refs.h                 |  6 ++++
 sequencer.c            |  4 +++
 walker.c               |  4 +++
 11 files changed, 129 insertions(+), 39 deletions(-)
-- 
1.9.1.505.gd05696d
Next: Ronnie Sahlberg
Message 1 of 16 in “Make update refs more atomic”
  1. 0/3 Make update refs more atomicRonnie Sahlberg, Apr 14, 2014
  2. 1/3 refs.c: split writing and commiting a ref into two separate functionsRonnie Sahlberg, Apr 14, 2014
  3. Michael HaggertyApr 15, 2014
  4. 2/3 refs.c: split delete_ref_loose() into a separate flag-for-deletion and commit phaseRonnie Sahlberg, Apr 14, 2014
  5. Michael HaggertyApr 15, 2014
  6. 3/3 refs.c: change ref_transaction_commit to run the commit loops once all work is finishedRonnie Sahlberg, Apr 14, 2014
  7. Junio C HamanoApr 14, 2014
  8. Ronnie SahlbergApr 15, 2014
  9. Michael HaggertyApr 15, 2014
  10. Ronnie SahlbergApr 15, 2014
  11. Michael HaggertyApr 15, 2014
  12. Ronnie SahlbergApr 16, 2014
  13. Junio C HamanoApr 16, 2014
  14. Ronnie SahlbergApr 16, 2014
  15. Junio C HamanoApr 16, 2014
  16. Michael HaggertyApr 16, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.