diff options
author | 2011-11-09 13:34:17 -0400 | |
---|---|---|
committer | 2011-11-09 13:34:17 -0400 | |
commit | 393b6b1bde7e049845ff125f8a32e566d6bd7adb (patch) | |
tree | 620f791c3c801b73450d33a127de346c96e4d100 /doc/bugs/cyclic_drop.mdwn | |
parent | 56b8194470f0ddc1b3e1c51da8ca55a5c9c2eb05 (diff) |
problem that came to me at 2 am
Diffstat (limited to 'doc/bugs/cyclic_drop.mdwn')
-rw-r--r-- | doc/bugs/cyclic_drop.mdwn | 53 |
1 files changed, 53 insertions, 0 deletions
diff --git a/doc/bugs/cyclic_drop.mdwn b/doc/bugs/cyclic_drop.mdwn new file mode 100644 index 000000000..b43762e78 --- /dev/null +++ b/doc/bugs/cyclic_drop.mdwn @@ -0,0 +1,53 @@ +drop's verification that a remote still has content can fail +if the remote is also dropping the content at the same time. Each +repository checks that the other still has the content, and then both +drop it. Could also happen with larger cycles of repositories. + +--- + +Fixing this requires locking. (Well, there are other ways, like moving the +content to a holding area when checking if it's safe to drop, but they +seem complicated, and would be hard to implement for move --from.) + +Add per-content lock files. An exclusive lock is held on content when +it's in the process of being dropped, or moved. The lock is taken +nonblocking; if it cannot be obtained, something else is acting on the +content and git-annex should refuse to do anything. + +Then when checking inannex, try to take a shared lock. Note that to avoid +deadlock, this must be a nonblocking lock. If it fails, the status of +the content is unknown, so inannex should fail. Note that this needs to be +distinguishable from "not in annex". + +--- + +move --to can also be included in the cycle, since it can drop data. + +Consider move to a remote that already has the content and +is at the same time doing a drop (or a move). The remote +verifies the content is present on the movee, and removes its copy. +The movee removes its copy. + +So move --to needs to take the content lock on start. Then the inannex +will fail. + +-- + +move --from is similar. Consider a case where both the local and the remote +are doing a move --from. Both have the content, and confirm the other does, +via inannex checks. Then both run git-annex-shell dropkey, removing both +copies. + +So move --from needs to take the content lock on start, so the inannex will +fail. + +--- + +Another cycle might be running move --to and move --from on the same file, +locally. The exclusivity of the content lock solves this, as only one can +run at a time. + +--- + +Another cycle might involve move --from and drop, both run on the same +file, locally. Again, the exclusive lock solves this. |