From: Joey Hess Date: Thu, 14 Jul 2022 17:51:59 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~72^2~49 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=557542d621d391d8fc2e1046606119dc22801144;p=git-annex.git comment --- diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment new file mode 100644 index 0000000000..01138a7ea6 --- /dev/null +++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment @@ -0,0 +1,27 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2022-07-14T17:07:59Z" + content=""" +Writing to the journal is currently atomic. And git-annex does take +advantage of that atomicity, by not locking the journal when it's reading +from it in some cases, the most used of which is Annex.Branch.get. + +But, it's not guaranteed that an append is atomic. A short enough append +may be, but how short may vary, and it's not well defined. Here is an +example of a short write append that gets interrupted in the middle by a +kill signal: + +> Unfortunately as far as I can determine, in the POSIX and Linux +> standards, there is no way to work around this new behavior. +> There's no way to ensure that some amount of data no matter now small, +> even just two bytes, are written out to a file as an atomic transfer +> (either aborted and no bytes written or is completely written out.) + +So appending would need more locking of the journal, which would add +some overhead to everything. And especially would hurt concurrency. + +Also, the journal is currently crash-safe. Even if there's a sudden +power loss, the write either completed or didn't happen. Appending +would lose that nice property. +"""]] diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment new file mode 100644 index 0000000000..449c185690 --- /dev/null +++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2022-07-14T17:45:31Z" + content=""" +@yarikoptic ok, please check and, if you can do that, +I'll implement the buffering of urls for a key. + +It looks like appending is not feasible.. + +Only other approach I can think of would be to have a switch that makes +git-annex buffer branch writes in memory, rather than using the journal, +and commit at the end, or when the buffer got too large. +"""]]