Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)

From: Drew Northup <n1xim.email@gmail.com>
Date: Jan 22, 2013, 04:31 UTC
Message-ID: <CAM9Z-nmJb3LGO3wLxPYhwc+7Cyw7J8q1E_PppNYQSmXKQ2ieQQ@mail.gmail.com>
In-Reply-To: <20130105161215.GA24900@sigill.intra.peff.net>

On Sat, Jan 5, 2013 at 11:12 AM, Jeff King <peff@peff.net> wrote:

Show 13 quoted lines

> On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote:
>
>> The general approach is to setup a transaction and either
>> commit or abort it.  A transaction can be setup by renaming
>> an appropriately setup directory to the "ref.lock" name.  If
>> the rename succeeds, the transaction is begun.  Any actor can
>> abort the transaction (up until it is committed) by simply
>> deleting the "ref.lock" directory, so it is not at risk of
>> going stale.
>
> Deleting a directory is not atomic, as you first have to remove the
> contents, putting it into a potentially inconsistent state. I'll assume
> you deal with that later...

I know I'm a bit late to the dance here, but FWIW the apparent atomicy (odd conjugation there) of directory deletion depends largely upon the filesystem and VFS api in use. It is not unheard of that a delete operation actually consist of moving the reference to the item's own allocation marker into a "trashcan" to be cleaned up after later. In other words, I'd not advise planning on directory deletes always being atomic nor always not being atomic.

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59