From: Joey Hess Date: Mon, 7 Dec 2020 20:55:07 +0000 (-0400) Subject: annex.stalldetection docs X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~2^2^2~76^2~393^2~6 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=2cb3f3a99dc5672c88b457c3d4549081459fff99;p=git-annex.git annex.stalldetection docs Not implemented yet. This commit was sponsored by Svenne Krap on Patreon. --- diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn index d19f333c09..2ee80c369f 100644 --- a/doc/git-annex.mdwn +++ b/doc/git-annex.mdwn @@ -1392,6 +1392,31 @@ Remotes are configured using these settings in `.git/config`. When making multiple retries of the same transfer, the delay doubles after each retry. (default 1) +* `remote..annex-stalldetecton`, `annex.stalldetection` + + This lets stalled or too-slow transfers be detected, and dealt with, so + rather than getting stuck, git-annex will cancel the stalled operation. + When this happens, the transfer will be considered to have failed, so + settings like annex.retry will control what it does next. + + This is not enabled by default, because it can make git-annex use + more resources. In order to cancel stalls, git-annex has to run + transfers in separate processes (one per concurrent job). So it + may need to open more connections to a remote than usual, or + the communication with those processes may make it a bit slower. + + The value specifies how much data git-annex should expect to see + flowing, minimum, when it's not stalled, over a given period of time. + The format is "$amount/$timeperiod". + + For example, to detect outright stalls where no data has been transferred + after 30 seconds: `git config annex.stalldetection "0KiB/60s"` + + Or, if you have a remote on a USB drive that is normally capable of + several megabytes per second, but has bad sectors where it gets + stuck for a long time, you could use: + `git config remote.usbdrive.annex-stalldetection "1MB/1m"` + * `remote..annex-checkuuid` This only affects remotes that have their url pointing to a directory on