correction

diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
index 8d38464e46663438f314b566cfa503ca12455e8b..65f496130940173d26414001570be8ce91c3a52e 100644 (file)
--- a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
@@ -3,11 +3,20 @@
  subject="""comment 4"""
  date="2020-01-30T16:44:52Z"
  content="""
-When git-annex downloads chunks, it uses a single file and seeks forward to
-the next chunk boundry when resuming, for example.
+When git-annex downloads chunks, it downloads one chunk at a time
+(no parallelisation downloads of chunks of the same key) to either a temp
+file or a memory buffer, decrypts if necessary, and then appends the
+chunk to the destination file.
 
-I agree with chrysn's analysis on all points.
+Since chunks are often stored entirely in ram, the chunk size is typically
+a small fraction of ram. It seems unlikely to me that the kernel would
+often decide to unncessarily flush a small write to a temp file out to disk
+and drop it from the cache when the very next operation after writing the
+file is reading it back in.
+
+chrysn's analysis seems right.
 
 Also, this smells of premature optimisation, and tying it to features that
-have not even been agreed on, let alone implemented or profiled, is weird.
+have not even been agreed on, let alone implemented, makes it kind of super
+low priority?
 """]]