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

correction

Browse source
This commit is contained in:
Joey Hess 2020-01-30 13:04:53 -04:00
parent 962f1f2363
commit c08d5612ee
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 13 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

17
doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
View file

@ -3,11 +3,20 @@
subject="""comment 4""" subject="""comment 4"""
date="2020-01-30T16:44:52Z" date="2020-01-30T16:44:52Z"
content=""" content="""
When git-annex downloads chunks, it uses a single file and seeks forward to When git-annex downloads chunks, it downloads one chunk at a time
the next chunk boundry when resuming, for example. (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 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?
"""]] """]]