From f5616024845002a5f7a5cf0f7f05356e0f36ceba Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 15 Jul 2022 11:10:40 -0400 Subject: [PATCH] comment --- ..._dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment new file mode 100644 index 0000000000..120e2e1f4c --- /dev/null +++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 9""" + date="2022-07-15T15:05:32Z" + content=""" +Rather than buffering in memory, it could buffer to a temporary journal, +and merge that with the main journal at the end. That would let it append +in place without worrying about locking, and memory use would not matter +either. In the common case, files could just be moved from the temp journal +to the main journal, which would be cheap. + +Same as buffering in memory, this would change the normal behavior where +other processes can see the changes made by a --batch process while it's +running. So it would need to be a non-default mode. + +I think though, that before implementing any of these things, I should +first benchmark how much overhead there would be in locking the journal +around read operations. +"""]]