update
This commit is contained in:
parent
70e2fca257
commit
173500872f
1 changed files with 0 additions and 18 deletions
|
@ -69,24 +69,6 @@ Planned schedule of work:
|
||||||
command behave non-ideally, the same as the thread concurrency
|
command behave non-ideally, the same as the thread concurrency
|
||||||
problems.
|
problems.
|
||||||
|
|
||||||
* implement size-based balancing, so all balanced repositories are around
|
|
||||||
the same percent full, perhaps as another preferred
|
|
||||||
content expression.
|
|
||||||
|
|
||||||
* `fullybalanced=foo:2` can get stuck in suboptimal situations. Eg,
|
|
||||||
when 2 out of 3 repositories are full, and the 3rd is mostly empty,
|
|
||||||
it is no longer possible to add new files to 2 repositories.
|
|
||||||
Moving some files from one of the full repositories to the empty one
|
|
||||||
would improve things, but is there any way for fullybalanced to know
|
|
||||||
when it makes sense to do that?
|
|
||||||
|
|
||||||
If this is not resolved, it may be better to lose the ":number" part
|
|
||||||
of balanced and fullybalanced. With 1 copy balanced, this situation does
|
|
||||||
not occur. Users wanting 2 copies can have 2 groups which are each
|
|
||||||
balanced, although that would mean more repositories on more drives.
|
|
||||||
|
|
||||||
Size based rebalancing may offer a solution; see design.
|
|
||||||
|
|
||||||
* `git-annex info` in the limitedcalc path in cachedAllRepoData
|
* `git-annex info` in the limitedcalc path in cachedAllRepoData
|
||||||
double-counts redundant information from the journal due to using
|
double-counts redundant information from the journal due to using
|
||||||
overLocationLogs. In the other path it does not, and this should be fixed
|
overLocationLogs. In the other path it does not, and this should be fixed
|
||||||
|
|
Loading…
Reference in a new issue