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

Merge branch 'bwlimit'

Browse source
This commit is contained in:
Joey Hess 2021-09-22 15:27:28 -04:00
commit fc9abca231
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
16 changed files with 149 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/git-annex.mdwn
View file

@ -1384,6 +1384,18 @@ 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.<name>.annex-bwlimit`, `annex.bwlimit`
This can be used to limit how much bandwidth is used for a transfer
from or to a remote.
For example, to limit transfers to 1 mebibyte per second:
`git config annex.bwlimit "1MiB"`
This will work with many remotes, including git remotes, but not
for remotes where the transfer is run by a separate program than
git-annex.
* `remote.<name>.annex-stalldetecton`, `annex.stalldetection`
Configuring this lets stalled or too-slow transfers be detected, and

25
doc/todo/bwlimit.mdwn
View file

@ -10,5 +10,26 @@ works, it will probably work to put the delay in there. --[[Joey]]
[[confirmed]]
> Implmentation in progress in the `bwlimit` branch. Seems to work, but see
> commit message for what still needs to be done. --[[Joey]]
> Implemented and works well.
>
> A local git remote, when resuming an interrupted
> transfer, has to hash the file (with default annex.verify settings),
> and that hashing updates the progress bar, and so the bwlimit can kick
> in and slow down that initial hashing, before any data copying begins.
> This seems perhaps ok; if you've bwlimited a local git remote,
> remote you're wanting to limit disk IO. Only reason it might not be ok
> is if the intent is to limit IO to the disk containing the remote
> but not the one containing the annex repo. (This also probably
> holds for the directory special remote.)
>
> Other remotes, including git over ssh, when resuming don't have that
> problem. Looks like chunked special remotes narrowly avoid it, just
> because their implementation choose to not do incremental verification
> when resuming. It might be worthwhile to differentiate between progress
> updates for incremental verification setup and for actual transfers, and
> only rate limit the latter, just to avoid fragility in the code.
> I have not done so yet though, and am closing this..
> --[[Joey]]
[[done]]