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
|
||||
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
|
||||
double-counts redundant information from the journal due to using
|
||||
overLocationLogs. In the other path it does not, and this should be fixed
|
||||
|
|
Loading…
Reference in a new issue