From 1c270d32513bd3ee23d5a3b6fa4c2e07acc238c7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 21 May 2025 13:05:06 -0400 Subject: [PATCH] comment --- ...2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment diff --git a/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment b/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment new file mode 100644 index 0000000000..2f3af14153 --- /dev/null +++ b/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2025-05-21T16:39:53Z" + content=""" +I think this is the same system that there will be a talk about at +Distribits 2025? I have been looking forward to that talk. + +@nobodyinperson seems on the right track with the `sequential=tape:1` idea. +And it seems fairly easy to implement using the same building blocks as +`sizebalanced`. + +Relatedly, I wonder about sequential reading when a big `git-annex get` +is run. Do you have some solution for that in mind? I could imagine doing +something similar to Amazon Glacier, where the first get of a file fails, +but is queued for later retrival from tape, allowing multiple requests to +be ordered more efficiently. +"""]]