On Thu, Feb 25, 2016 at 3:37 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2016-02-20 at 15:59 +0700, Duy Nguyen wrote: >> On Thu, Feb 18, 2016 at 12:17 PM, David Turner < >> dturner@xxxxxxxxxxxxxxxx> wrote: >> > LMDB has a few features that make it suitable for usage in git: >> > ... >> >> I'm reading lmdb documents and hitting the caveat section [1]. >> Random thoughts >> >> * "There is normally no pure read-only mode, since readers need write >> access to locks and lock file.". >> >> This will be a problem for server side that serves git:// protocol >> only. Some of those servers disable write access to the entire >> repository and git still works fine (but won't when lmdb is used). >> Should we do something in this case? Just tell server admins to relax >> file access, or use MDB_NOLOCK (and when? based on config var?) > > MDB_NOLOCK is a good idea. I'm going to add this to the "Weaknesses" > section of the docs and plan to fix it later, unless you feel strongly > otherwise. No I'm fine as long as it's documented. I was a bit disappointed when I found out about this because after reading lmdb paper I almost suggested we add lmdb to git.git as a submodule and prepare it to be the next default ref backend. The quest for the "next generation" default ref backend continues. >> * "Avoid long-lived transactions...." >> >> OK we don't have a problem with this. But it makes me realize lmdb >> transactions do not map with ref transactions. We don't open lmdb >> transaction at ref_transaction_begin(), for example. Is it simply >> more >> convenient to do transactions the current way, or is it impossible or >> incorrect to attach lmdb transactions to ref_transaction_*()? > > That was what I did originally, but reviewers here noted that it had > some problems: > 1. What if, while a transaction is open, git opens a subprocess that > wants to make its own transaction? There can only be one writer > transaction open at a time. > 2. As you note, long-lived transactions. > > Also, the files backend also doesn't do any locking until the last > moment, and it's reasonable to try to be compatible with that. Some of these should be kept in the commit message for future reference. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html