RE: reftable [v5]: new ref storage format
- From
- David Turner <david.turner@twosigma.com>
- Date
- Aug 7, 2017, 15:40 UTC
- Message-ID
- <833bc420609e452e8837862eb90f6a43@exmbdft7.ad.twosigma.com>
- In-Reply-To
- <CAJo=hJsEaKH40WnhxqvkASpiXnV8ipc+b1zrZ9VEjqRjpJ17Qg@mail.gmail.com>
Show 8 quoted lines
> -----Original Message----- > From: Shawn Pearce [mailto:spearce@spearce.org] > In git-core, I'm worried about the caveats related to locking. Git tries to work > nicely on NFS, and it seems LMDB wouldn't. Git also runs fine on a read-only > filesystem, and LMDB gets a little weird about that. Finally, Git doesn't have > nearly the risks LMDB has about a crashed reader or writer locking out future > operations until the locks have been resolved. This is especially true with shared > user repositories, where another user might setup and own the semaphore.
FWIW, git has problems with stale lock file in the event of a crash (refs/foo.lock might still exist, and git does nothing to clean it up).
In my testing (which involved a *lot* of crashing), I never once had to clean up a stale LMDB lock. That said, I didn't test on a RO filesystem.