Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
941ea993dc
12 changed files with 125 additions and 0 deletions
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 5"
|
||||
date="2014-03-06T18:12:57Z"
|
||||
content="""
|
||||
Again the accept message does not seem to be related to dbus. A dbus client has no reason to do that; a web server does. The use of `O_NONBLOCK` with accept4 seems likely to be the culprit to me.
|
||||
|
||||
How frequently is dbus mentioned in the log?
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 5"
|
||||
date="2014-03-06T18:14:37Z"
|
||||
content="""
|
||||
auto-repair is only done if git fsck detects a problem. You can run git fsck yourself to see.
|
||||
"""]]
|
|
@ -0,0 +1,15 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://grossmeier.net/"
|
||||
nickname="greg"
|
||||
subject="comment 8"
|
||||
date="2014-03-06T18:54:08Z"
|
||||
content="""
|
||||
The last key listed by unused (111 of 111):
|
||||
|
||||
[[!format sh \"\"\"
|
||||
greg@x200s:~/Documents/.git/annex/objects/q4/22/SHA256E-s12289--68a93144e03274664d50754882bdaf196134e06ec2b912157bdccae436d577d6.ods$ ls
|
||||
SHA256E-s12289--68a93144e03274664d50754882bdaf196134e06ec2b912157bdccae436d577d6.ods.cache
|
||||
SHA256E-s12289--68a93144e03274664d50754882bdaf196134e06ec2b912157bdccae436d577d6.ods.map
|
||||
greg@x200s:~/Documents/.git/annex/objects/q4/22/SHA256E-s12289--68a93144e03274664d50754882bdaf196134e06ec2b912157bdccae436d577d6.ods$
|
||||
\"\"\"]]
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnR6E5iUghMWdUGlbA9CCs8DKaoigMjJXw"
|
||||
nickname="Efraim"
|
||||
subject="comment 1"
|
||||
date="2014-03-06T20:37:36Z"
|
||||
content="""
|
||||
not quite a sync button, but when I want to force sync now I turn off and turn on sync for one of the repos from the webapp and then it syncs.
|
||||
"""]]
|
|
@ -0,0 +1,18 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
|
||||
nickname="Justin"
|
||||
subject="comment 3"
|
||||
date="2014-03-06T18:21:53Z"
|
||||
content="""
|
||||
> How many files copied are we talking about before it begins to fail?
|
||||
|
||||
Tens of thousands of files processed, but many of them were already on the other remote so didn't invoke cp (or anything else). ~3300 invocations of cp.
|
||||
|
||||
I saved a log of ps aux, and, while the memory used by git annex remains relatively constant, I do observe /tons/ of zombie processes. 3300, actually.
|
||||
|
||||
I didn't check all of them, but all of the zombie pids I checked appear to have corresponded to this command:
|
||||
|
||||
/home/pi/git-annex.linux/shimmed/git/git --git-dir=/home/pi/hdd/annex/.git --work-tree=/home/pi/hdd/annex cat-file --batch
|
||||
|
||||
Perhaps git annex is forgetting to reap this processes?
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 4"
|
||||
date="2014-03-06T18:32:33Z"
|
||||
content="""
|
||||
Old versions of git-annex have known bugs involving zombies. What version?
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
|
||||
nickname="Justin"
|
||||
subject="comment 5"
|
||||
date="2014-03-06T18:35:00Z"
|
||||
content="""
|
||||
5.20140221-g1a47f5f -- I just downloaded it a week or two ago.
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 6"
|
||||
date="2014-03-06T18:38:43Z"
|
||||
content="""
|
||||
Hmm, that version should only start git cat-file --batch a maximum of 10 times (if it is crashing for some reason), and appears to wait on the process if it does crash. And if not, should only start one.
|
||||
|
||||
I think you need to post some git-annex --debug output , to show when it's running this command.
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 7"
|
||||
date="2014-03-06T18:40:26Z"
|
||||
content="""
|
||||
Actually, NM, I have reproduced the bug.
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 8"
|
||||
date="2014-03-06T20:21:16Z"
|
||||
content="""
|
||||
Analysis: Remote.Git's onLocal calls Annex.new to make a new AnnexState for the local remote. This state is not cached, and is regenerated for each file. Since it runs a Annex.Branch check of the location log on the remote, it needs to start catFile, and since the state is not reused, a new CatFileHandle is allocated each time. I'm not sure, but there may have been a recent-ish change that caused the location log to get checked and so catfile to be run; the general inneficiency of making a new AnnexState each time is not new.
|
||||
|
||||
Fixing this by caching the AnnexState will not only fix the resource leak, but should speed up local to local copies significantly!
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 9"
|
||||
date="2014-03-06T21:17:14Z"
|
||||
content="""
|
||||
Fixed in git. Also reduced the non-data-transfer work done by `git-annex copy` by around 8%.
|
||||
|
||||
I'm going to move this thread to [[bugs]] so I can close it. ;)
|
||||
"""]]
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.146"
|
||||
subject="comment 5"
|
||||
date="2014-03-06T18:22:31Z"
|
||||
content="""
|
||||
Do you edit this file in multiple places? This could be an occurance of this bug: [[bugs/direct_mode_merge_can_overwrite_local,_non-annexed_files]] which is fixed in the latest release.
|
||||
|
||||
If the program that writes the workspace.xml file did so by first deleting it, and then writing the new version, this could result in the assistant committing the deletion, which makes the new version a local, non-annexed file, and then if a pull is received that modified the file, I think the above bug could happen.
|
||||
|
||||
You could tell if this was the case by looking at the git log of the directory containing the file, and see if it has been repeatedly deleted and added back to the repository. The git log snippet you pasted unfortunately does not let me tell this information.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue