comment and analysis
This commit is contained in:
parent
ad2a6d45db
commit
4c35d58bfe
2 changed files with 31 additions and 0 deletions
|
@ -20,6 +20,24 @@ remotes, without needing to set mincopies to 0 and risk losing content.
|
|||
b) wait long enough or document well enough to be sure that situation
|
||||
never happens.
|
||||
|
||||
> Maybe this second part is not a problem actually? Analysis follows:
|
||||
>
|
||||
> There are 2 git-annex
|
||||
> instances A and B, and 2 special remotes X and Y. A is using the old
|
||||
> program that does not support locking, B uses the new program that does.
|
||||
> Both X and Y have a copy of an object.
|
||||
>
|
||||
> If A is dropping from X, it will not trust Y to satisfy mincopies,
|
||||
> since A cannot lockContent Y. So it will not drop from X.
|
||||
>
|
||||
> If B is dropping from Y, it can lockContent X, and so the drop
|
||||
> succeeds.
|
||||
>
|
||||
> It seems it's ok for B to trust lockContent X, even though A does
|
||||
> not check if X is locked when dropping from it. Because A will not
|
||||
> drop from X unless it's able to satisfy mincopies by locking the
|
||||
> content somewhere else. --[[Joey]]
|
||||
|
||||
* directory could use fcntl locking
|
||||
|
||||
This would need a transition, because dropping from directory first needs
|
||||
|
@ -29,6 +47,8 @@ remotes, without needing to set mincopies to 0 and risk losing content.
|
|||
the first change, then wait several months or years before making the
|
||||
second change.
|
||||
|
||||
> Update: See analysis above, should also apply here.
|
||||
|
||||
Also, the directory might be on a filesystem that does not support
|
||||
locking, with various failure modes. And unlike a git-annex repo,
|
||||
there's nowhere in a directory special remote to record information about
|
||||
|
|
|
@ -0,0 +1,11 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2021-04-12T16:30:06Z"
|
||||
content="""
|
||||
Both of these ideas above seem to suffer from race conditions,
|
||||
which lockContent needs to prevent. lockContent needs the remote to
|
||||
support an actual exclusive locking operation.
|
||||
|
||||
Do you have an external special remote that could actually support that?
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue