Jeff King <peff@xxxxxxxx> wrote: >On Thu, Dec 27, 2012 at 04:11:51PM -0700, Martin Fick wrote: >> My idea is based on using filenames to store sha1s instead of >> file contents. To do this, the sha1 one of a ref would be >> stored in a file in a directory named after the loose ref. I >> believe this would then make it possible to have lockless >> atomic ref updates by renaming the file. >> >> To more fully illustrate the idea, imagine that any file >> (except for the null file) in the directory will represent the >> value of the ref with its name, then the following >> transitions can represent atomic state changes to a refs >> value and existence: > >Hmm. So basically you are relying on atomic rename() to move the value >around within a directory, rather than using write to move it around >within a file. Atomic rename is usually something we have on local >filesystems (and I think we rely on it elsewhere). Though I would not >be >surprised if it is not atomic on all networked filesystems (though it >is >on NFS, at least). Yes. I assume this is OK because doesn't git already rely on atomic renames? For example to rename the new packed-refs file to unlock it? ... >> 3) To create a ref, it must be renamed from the null file (sha >> 0000...) to the new value just as if it were being updated >> from any other value, but there is one extra condition: >> before renaming the null file, a full directory scan must be >> done to ensure that the null file is the only file in the >> directory (this condition exists because creating the >> directory and null file cannot be atomic unless the filesystem >> supports atomic directory renames, an expectation git does >> not currently make). I am not sure how this compares to >> today's approach, but including the setup costs (described >> below), I suspect it is slower. > >Hmm. mkdir is atomic. So wouldn't it be sufficient to just mkdir and >create the correct sha1 file? But then a process could mkdir and die leaving a stale empty dir with no reliable recovery mechanism. Unfortunately, I think I see another flaw though! :( I should have known that I cannot separate an important check from its state transitioning action. The following could happen: A does mkdir A creates null file A checks dir -> no other files B checks dir -> no other files A renames null file to abcd C creates second null file B renames second null file to defg One way to fix this is to rely on directory renames, but I believe this is something git does not want to require of every FS? If we did, we could Change #3 to be: 3) To create a ref, it must be renamed from the null file (sha 0000...) to the new value just as if it were being updated from any other value. (No more scan) Then, with reliable directory renames, a process could do what you suggested to a temporary directory, mkdir + create null file, then rename the temporary dir to refname. This would prevent duplicate null files. With a grace period, the temporary dirs could be cleaned up in case a process dies before the rename. This is your approach with reliable recovery. >> I don't know how this new scheme could be made to work with >> the current scheme, it seems like perhaps new git releases >> could be made to understand both the old and the new, and a >> config option could be used to tell it which method to write >> new refs with. Since in this new scheme ref directory names >> would conflict with old ref filenames, this would likely >> prevent both schemes from erroneously being used >> simultaneously (so they shouldn't corrupt each other), except >> for the fact that refs can be nested in directories which >> confuses things a bit. I am not sure what a good solution to >> this is? > >I think you would need to bump core.repositoryformatversion, and just >never let old versions of git access the repository directly. Not the >end of the world, but it certainly increases deployment effort. If we >were going to do that, it would probably make sense to think about >solving the D/F conflict issues at the same time (i.e., start calling >"refs/heads/foo" in the filesystem "refs.d/heads.d/foo.ref" so that it >cannot conflict with "refs.d/heads.d/foo.d/bar.ref"). Wouldn't you want to use a non legal ref character instead of dot? And without locks, we free up more of the ref namespace too I think? (Refs could end in ".lock") -Martin Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum -- 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