aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-04-19 17:56:56 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-04-19 17:56:56 -0400
commit936ad63cf47287549412fa0013bcc975c11026d7 (patch)
tree9c67fb1ffd98eb105be95e38a633a5b80eb115e0
parent2b742dcd780d185ff81bbaa4a8d675eb945dcb66 (diff)
heard from hS3 author
-rw-r--r--doc/bugs/S3_memory_leaks.mdwn11
1 files changed, 9 insertions, 2 deletions
diff --git a/doc/bugs/S3_memory_leaks.mdwn b/doc/bugs/S3_memory_leaks.mdwn
index f0522304c..418260125 100644
--- a/doc/bugs/S3_memory_leaks.mdwn
+++ b/doc/bugs/S3_memory_leaks.mdwn
@@ -1,14 +1,21 @@
S3 has two memory leaks.
+## with encryption
+
One only occurs with encryption. It was was fixed for bup, but
not yet for S3, in 5985acdfad8a6791f0b2fc54a1e116cee9c12479.
(The fix I used for bup doesn't seem to work with S3.)
+## always
+
The other occurs independant of encryption use. Copying a 100 mb
file to S3 causes an immediate sharp memory spike to 119 mb.
Copying the file back from S3 causes a slow memory increase toward 119 mb.
It's likely that this memory is used by the hS3 library, if it does not
construct the message to Amazon lazily. (And it may not be possible to
-construct it lazily, if it includes checksum headers..) I have
-emailed the hS3 author about this.
+construct it lazily, if it includes checksum headers..)
+
+I have emailed the hS3 author about this. He wrote back quickly, seems
+only getting the size of the file is causing it to be buffered, and a quick
+fix should be forthcoming.
--[[Joey]]