comment
authorJoey Hess <joeyh@joeyh.name>
Fri, 15 Jul 2022 15:10:40 +0000 (11:10 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 15 Jul 2022 15:10:40 +0000 (11:10 -0400)
doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment [new file with mode: 0644]

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 (file)
index 0000000..120e2e1
--- /dev/null
@@ -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.
+"""]]