balanced preferred content and --rebalance
This all works fine. But it doesn't check repository sizes yet, and without repository size checking, once a repository gets full, there will be no other repository that will want its files. Use of sha2 seems unncessary, probably alder2 or md5 or crc would have been enough. Possibly just summing up the bytes of the key mod the number of repositories would have sufficed. But sha2 is there, and probably hardware accellerated. I doubt very much there is any security benefit to using it though. If someone wants to construct a key that will be balanced onto a given repository, sha2 is certianly not going to stop them.
This commit is contained in:
parent
152c87140b
commit
3ce2e95a5f
11 changed files with 169 additions and 17 deletions
|
@ -30,9 +30,17 @@ Planned schedule of work:
|
|||
|
||||
## work notes
|
||||
|
||||
* onward to balanced preferred content! But it depends on
|
||||
[[track_free_space_in_repos_via_git-annex_branch]] so that will be the
|
||||
first task.
|
||||
* balanced= and fullybalanced= need to limit the set of repositories to
|
||||
ones with enough free space to contain a key.
|
||||
|
||||
* Add `git-annex size` command.
|
||||
|
||||
* Implement [[track_free_space_in_repos_via_git-annex_branch]]
|
||||
|
||||
## completed items for August's work on balanced preferred content
|
||||
|
||||
* Balanced preferred content basic implementation, including --rebalance
|
||||
option.
|
||||
|
||||
## completed items for August's work on git-annex proxy support for exporttre
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue