mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment and analysis

Browse source
This commit is contained in:
Joey Hess 2021-04-12 12:54:46 -04:00
parent ad2a6d45db
commit 4c35d58bfe
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 31 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/lockContent_for_special_remotes.mdwn
View file

@ -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 b) wait long enough or document well enough to be sure that situation
never happens. 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 * directory could use fcntl locking
This would need a transition, because dropping from directory first needs 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 the first change, then wait several months or years before making the
second change. second change.
> Update: See analysis above, should also apply here.
Also, the directory might be on a filesystem that does not support Also, the directory might be on a filesystem that does not support
locking, with various failure modes. And unlike a git-annex repo, locking, with various failure modes. And unlike a git-annex repo,
there's nowhere in a directory special remote to record information about there's nowhere in a directory special remote to record information about

11
doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment Normal file
View file

@ -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?
"""]]