avoid double-connect to unreachable ssh remote
When git-annex-shell p2pstdio fails with 255, it's because the ssh server is not reachable. Avoid running the fallback action in this case, since it would just try a second time to connect, and presumably fail. Note that the closed P2PSshConnection will not be stored in the pool, so the next request tries again to connect. This is just the right behavior; when the remote becomes reachable again, the same git-annex process will start using it. This commit was sponsored by Ole-Morten Duesund on Patreon.
This commit is contained in:
parent
e36ceb7448
commit
c3df5d1f10
6 changed files with 43 additions and 37 deletions
|
@ -37,20 +37,6 @@ good to unify with it as much as possible.
|
|||
Mostly implemented now, but need to test and think about these
|
||||
implementation todos:
|
||||
|
||||
* git-annex-shell p2pstdio currently always verifies content it receives.
|
||||
git-annex-shell recvkey has a speed optimisation, when it's told the file
|
||||
being sent is locked, it can avoid an expensive verification, when
|
||||
annex.verify=false. (Similar for transfers in the other direction.)
|
||||
|
||||
The P2P protocol does not have a way to communicate when that happens,
|
||||
and forces AlwaysVerify.
|
||||
|
||||
It would be nice to support that, but if it added an extra round trip
|
||||
to the P2P protocol, that could lose some of the speed gains.
|
||||
|
||||
My first attempt to implement this failed miserably due to a Free monad
|
||||
type check problem I could not see a way around.
|
||||
|
||||
* What happens when the assistant is running and some connections are open
|
||||
and it moves between networks?
|
||||
|
||||
|
|
|
@ -20,8 +20,3 @@ At some point in the future, once all git-annex and git-annex-shell
|
|||
can be assumed to be upgraded to 6.20180312, this fallback can be removed.
|
||||
It will allows removing a lot of code from git-annex-shell and a lot of
|
||||
fallback code from Remote.Git.
|
||||
|
||||
Removing the fallback code will also improve speed of dealing with remotes
|
||||
that are not reachable, since currently git-annex tries first to open a p2p
|
||||
connection, and then tries the fallback, so it has to wait for two
|
||||
TCP connection timeouts.
|
||||
|
|
|
@ -0,0 +1,16 @@
|
|||
git-annex-shell p2pstdio currently always verifies content it receives.
|
||||
git-annex-shell recvkey has a speed optimisation, when it's told the file
|
||||
being sent is locked, it can avoid an expensive verification, when
|
||||
annex.verify=false. (Similar for transfers in the other direction.)
|
||||
|
||||
The P2P protocol does not have a way to communicate when that happens,
|
||||
and forces AlwaysVerify.
|
||||
|
||||
It would be nice to support that, but if it added an extra round trip
|
||||
to the P2P protocol, that could lose some of the speed gains.
|
||||
The best way seems to be to add a new protocol version, where DATA
|
||||
has an extra byte at the end that is "1" when the file didn't change
|
||||
as it was transferred, and "0" when it did.
|
||||
|
||||
My first attempt to implement this failed miserably due to a Free monad
|
||||
type check problem I could not see a way around.
|
Loading…
Add table
Add a link
Reference in a new issue