| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Some nice efficiency gains here for list appending, although mostly
the small size of the transfer queue makes them irrelivant.
|
| |
|
|
|
|
|
|
| |
Without this, a very large batch add has commits of sizes approx
5000, 2500, 1250, etc down to 10, and then starts over at 5000.
This fixes it so it's 5000+ every time.
|
|
|
|
| |
a higher trust level.
|
|\ |
|
| |
| |
| |
| |
| | |
A recent change made existing symlinks be re-staged. That does not need to
be done during the startup scan though.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That hook updates associated file bookkeeping info for direct mode.
But, everything already called addAssociatedFile when adding/changing a
file. It only needed to also call removeAssociatedFile when deleting a file,
or a directory.
This should make bulk adds faster, by some possibly significant amount.
Bulk removals may be a little slower, since it has to use catKeyFile now
on each removed file, but will still be faster than adds.
|
|
|
|
| |
Converted back to the wrong type, oops.
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a tradeoff between making less frequent commits, and
needing to use memory to store all the changes that are coming
in. At 10 thousand, it needs 150 mb of memory. 5 thousand drops
that down to 90 mb or so.
This also turns out to have significant imact on total run time.
I benchmarked 10k changes taking 27 minutes. But two 5k batches
took only 21 minutes.
|
| |
| |
| |
| |
| |
| |
| | |
If an add failed, we should lose the KeySource, since it, presumably,
differs due to a change that was made to the file.
(The locked down file is already deleted.)
|
| | |
|
| | |
|
|/ |
|
|\ |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Turns out that a lot of the time spent in a bulk add was just updating the
add alert to rotate through each file that was added. Showing one alert
makes for a significant speedup.
Also, when the webapp is open, this makes it take quite a lot less cpu
during bulk adds.
Also, it lets the user know when a bulk add happened, which is sorta
nice..
|
|
|
|
| |
limit behavior
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This better handles error messages formatted for console display, by
adding a <br> after each line.
Hmm, I wonder if it'd be worth pulling in a markdown formatter, and running
the messages through it?
|
|/ |
|
|
|
|
|
|
|
| |
In the case of the inotify limit warning, particularly, if it happens once
it will be happening repeatedly, and so combining alerts resulted in a
much too large alert message that took up a lot of memory and was too
large for the webapp to display.
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
I have a report that this is necessary for freebsd.
It seemed not necessary for OSX, but even there the kqueue
man page says to include this header (along with sys/time.h
which it already does).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That is very dodgy; it makes *every* C file compiled have that header added
to it. Apparently sys/event.h needs some other header files to be included
on some OS's, and so this leads to compile failures in completely unrelated
places to the code that actually uses sys/event.h
This reverts commit a767040a53182cde16434cba686252bbaf776cf9, which added
this with no rationalle and I must have missed in amoung the other patches
when merging.
Also, Utility/kqueue.c already includes sys/event.h
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
fails to run git-annex-shell.
|
|\ |
|