From e0e16187a87c2dc42b54b655a5aa19bbdcecf9c3 Mon Sep 17 00:00:00 2001 From: prancewit Date: Tue, 13 Sep 2022 19:45:23 +0000 Subject: [PATCH] Added a comment: My current use case --- ...t_3_4f18712f974f85c3cef810714d304d85._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment new file mode 100644 index 0000000000..1edb09b9d0 --- /dev/null +++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="prancewit" + avatar="http://cdn.libravatar.org/avatar/f6cc165b68a5cca3311f9a1cd7fd027c" + subject="My current use case" + date="2022-09-13T19:45:23Z" + content=""" +Thanks for the response, Joey. + +Let me start by providing more details the use case where I noticed this slowness. + +I was using a slow remote with a lot of chunks. I stopped the upload and wanted to do a cleanup of the uploaded chunks. That's when I noticed that git-annex was requesting a removal of each chunk individually, even ones that never actually got uploaded. + +In this particular case, I could \"preload\" the data since I knew which chunks were valid and which ones weren't to make it faster (though I actually just waited it out) + +Also, like you mentioned, this MULTIREMOVE is most useful for this specific case so a more generic solution will definitely be much better. +"""]]