b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
I've been running some large transfers with the assistant, and looking at
|
|
ways to improve performance. (I also found and fixed a zombie process
|
|
leak.)
|
|
|
|
----
|
|
|
|
One thing I noticed is that the assistant pushes changes to the git-annex
|
|
location log quite frequently during a batch transfer. If the files being
|
|
transferred are reasonably sized, it'll be pushing once per file transfer.
|
|
It would be good to reduce the number of pushes, but the pushes are
|
|
important in some network topologies to inform other nodes
|
|
when a file gets near to them, so they can get the file too.
|
|
|
|
Need to see if I can find a smart way to avoid some of the pushes.
|
|
For example, if we've just downloaded a file, and are queuing uploads
|
|
of the file to a remote, we probably don't need to push the git-annex
|
|
branch to the remote.
|
|
|
|
----
|
|
|
|
Another performance problem is that having the webapp open while transfers
|
|
are running uses significant CPU just for the browser to update the progress
|
|
bar. Unsurprising, since the webapp is sending the browser a new `<div>`
|
|
each time. Updating the DOM instead from javascript would avoid that;
|
|
the webapp just needs to send the javascript either a full `<div>` or a
|
|
changed percentage and quantity complete to update a single progress bar.
|
|
|
|
I'd prefer to wait on doing that until I'm able to use Fay to generate
|
|
Javascript from Haskell, because it would be much more pleasant.. will see.
|
|
|
|
----
|
|
|
|
Also a performance problem when performing lots of transfers, particularly
|
|
of small files, is that the assistant forks off a `git annex transferkey`
|
|
for each transfer, and that has to in turn start up several git commands.
|
|
|
|
Today I have been working to change that, so the assistant maintains a
|
|
pool of transfer processes, and dispatches each transfer it wants to make
|
|
to a process from the pool. I just got all that to build, although untested
|
|
so far, in the `transferpools` branch.
|