drop: Avoid redundant object directory thawing.

Sponsored-by: Dartmouth College's DANDI project

diff --git a/Annex/Content.hs b/Annex/Content.hs
index f01432669ebb02be0dcd3d74ee3d57ebe2f1b1dd..15d58e2e26674ae298423dab20f6fd4b9f480b0c 100644 (file)
--- a/Annex/Content.hs
+++ b/Annex/Content.hs
@@ -368,8 +368,16 @@ lockContentUsing contentlocker key fallback a = withContentLockFile key $ \mlock
                                cleanuplockfile lockfile
 #endif
 
-       cleanuplockfile lockfile = void $ tryNonAsync $ do
-               thawContentDir lockfile
+       cleanuplockfile lockfile = 
+               -- Often the content directory will be thawed already,
+               -- so avoid re-thawing, unless cleanup fails.
+               tryNonAsync (cleanuplockfile' lockfile) >>= \case
+                       Right () -> return ()
+                       Left _ -> void $ tryNonAsync $ do
+                               thawContentDir lockfile
+                               cleanuplockfile' lockfile
+       
+       cleanuplockfile' lockfile = do
                liftIO $ removeWhenExistsWith removeFile lockfile
                cleanObjectDirs lockfile
 

diff --git a/CHANGELOG b/CHANGELOG
index 137ba0d99a78d7cc4cef69874a72f4ea4fb250ea..3202d1afe57e01ec8fae0f451e45f84c7adb288b 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -5,6 +5,7 @@ git-annex (10.20250321) UNRELEASED; urgency=medium
     the git-annex branch.
   * Fix build without the assistant.
   * fsck: Avoid complaining about required content of dead repositories.
+  * drop: Avoid redundant object directory thawing.
 
  -- Joey Hess <id@joeyh.name>  Fri, 21 Mar 2025 12:27:11 -0400
 

diff --git a/doc/bugs/thawing_directory_-_takes_long_+_logs_twice/comment_1_b31f5a233587b86983188b600ce9cf5e._comment b/doc/bugs/thawing_directory_-_takes_long_+_logs_twice/comment_1_b31f5a233587b86983188b600ce9cf5e._comment
new file mode 100644 (file)
index 0000000..f319601
--- /dev/null
+++ b/doc/bugs/thawing_directory_-_takes_long_+_logs_twice/comment_1_b31f5a233587b86983188b600ce9cf5e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-03-26T14:45:38Z"
+ content="""
+Do you have `annex.freezecontent-command` / `annex.thawcontent-command`
+configured for this repo? Asking because I know you use it somewhere,
+and some expensive command might explain why thawing takes so long.
+
+As to the content directory perms, `drwxr-sr-x` is weird and the really
+weird part of it is the `s`. I don't see how git-annex would ever 
+set that bit itself.
+
+Here's what's going on with the repeated thawing:
+
+* Before it can drop the content, it has to take the drop lock, so thaws
+  the directory in order to write the lock file.
+* After taking the drop lock, it re-freezes. Of course this is not
+  necessary, but it avoids a complicated error unwind if it is later unable
+  to drop.
+* Then it thaws in order to delete the object file.
+* The final thaw is to delete the drop lock file. While the thaw is in
+  this situation unncessary, since it's left thawed after deleting the
+  object file, if the drop had failed it would get to this point with the
+  directory frozen, but would still want to delete the drop lock file,
+  and so would need to thaw it.
+
+I have now optimized away that final thaw. I don't think it makes sense to
+optimise away the first thaw/freeze cycle, because it would complicate
+error unwinding and there is anyway no indication it's slow.
+
+I don't know though, that the 2 minutes between the 2nd and 3rd thawing
+lines are caused by the actual chmod calls. Seems unlikely, unless you do
+have a thawcontent-command. It seems more likely that deleting the object
+file and whatever else happens at that point is what is taking 2 minutes.
+I suggest strace.
+"""]]