response
authorJoey Hess <joeyh@joeyh.name>
Mon, 30 Jan 2017 17:52:08 +0000 (13:52 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 30 Jan 2017 17:52:08 +0000 (13:52 -0400)
This commit was sponsored by Thomas Hochstein on Patreon.

doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment [new file with mode: 0644]

diff --git a/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment
new file mode 100644 (file)
index 0000000..89cc134
--- /dev/null
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-30T17:35:27Z"
+ content="""
+Generally git-annex takes longer the more files in the repository it needs
+to deal with. If a repository gets a great many files (typically 
+hundreds of thousands to millions), various inneficiencies in git annex
+git-annex will slow things down enough that it gets annoying.
+Splitting the files into different branches 
+(or separate repositories) is a common way to deal with that.
+
+Also, running on a spinning disk tends to be a lot slower than a SSD.
+
+Just for comparison, `git annex status` in a repository with 75000 files
+takes 0.5 seconds on my laptop's SSD. `git status` takes 0.2 seconds.
+
+In your particular case, the NTFS partition and/or v6
+mode seems likely to be the reason for slowdowns. Both git and git-annex
+record the inode numbers used for files in the repository. Those numbers
+are supposed to be stable, but mounting a filesystem on windows and then
+linux will make the inode numbers change. (Even remounting a FAT
+partition on linux will change the inodes, although that doesn't seem
+to happen for NTFS in a quick test).
+
+When the inodes have changed, much slower code paths get activated, since
+git and git-annex have to then assume the contents of the files may have
+changed since the last time they saw them. In a v6 repository where this
+has happened, `git status` is quite likely running `git-annex smudge`
+once per file in the working tree, which is quite slow.
+"""]]