Re: [PATCH v3 0/3] Make update refs more atomic
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 11, 2014, 22:27 UTC
- Message-ID
- <xmqqwqevpkna.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1397248790-10403-1-git-send-email-sahlberg@google.com>
Ronnie Sahlberg <sahlberg@google.com> writes:
Show 27 quoted lines
> 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.
Hmph. At least 5801 9350 and 9300 seem to fail with these three queued on top of mh/ref-transaction series.