From 3e047f05cf837652fe298d57920a8cd8ba6e9270 Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Thu, 18 Jan 2024 21:32:30 +0000 Subject: [PATCH 1/2] Added a comment --- ...comment_4_320828c8d39d1f030d1797b539dbb22e._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment new file mode 100644 index 0000000000..c3a991d4b1 --- /dev/null +++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="yarikoptic" + avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" + subject="comment 4" + date="2024-01-18T21:32:30Z" + content=""" +Thank you Joey for looking into it! FWIW, indeed I had `stalldetection = 1KB/120s` . But I believe I introduced it primarily for data \"download\", where git-annex actually IIRC keeps its monitoring of the file size as it is arriving. For the `copy` out, situation is indeed different and in case of assymmetric connections I even wondered if worth allowing different values for stalldetection-get and -put? + +In this particular case, since original report we did adjust rclone special remote to report PROGRESS back. I think it completed fine on few 1 large file uploads. I will tomorrow (after we get daily git-annex build in) run it \"on full\" for a good number of files and see what happens. +"""]] From 0270f4d8ed93472249e811756aaec841a2befcea Mon Sep 17 00:00:00 2001 From: imlew Date: Thu, 18 Jan 2024 23:09:21 +0000 Subject: [PATCH 2/2] Added a comment --- ...ment_2_ef89154903395025bb0a0408e1c23bdf._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment diff --git a/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment new file mode 100644 index 0000000000..e81f301998 --- /dev/null +++ b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="imlew" + avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed" + subject="comment 2" + date="2024-01-18T23:09:21Z" + content=""" +Using the standard transfer group wouldn't work in this situation because the remotes cannot be clients (among other reason because the server repo is bigger than the external drives). + +But from your answer I surmise that the local repo must want the files unless they are on the drives and no longer want them once they are on drives, is that correct? + +I will try letting it run overnight with the local repo's wanted being `\"not copies=2\"`. Hopefully sync will drop the local copy as soon as it has been transferred to the drive and not keep that for last. + +"""]]