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

avoid double-connect to unreachable ssh remote

Browse source 
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:
Joey Hess 2018-03-12 16:50:21 -04:00
parent e36ceb7448
commit c3df5d1f10
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 43 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol.mdwn
View file

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

5
doc/todo/p2p_protocol_flag_days.mdwn
View file

@ -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.

16
doc/todo/support_disabling_verification_of_transfer_over_p2p_protocol.mdwn Normal file
View file

@ -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.