Changes between Initial Version and Version 4 of Ticket #699


Ignore:
Timestamp:
2010-03-24T23:26:36Z (14 years ago)
Author:
davidsarah
Comment:

It seems more usable for this behaviour to be unconditional rather than an option: why would you not want to attempt to ensure that a file is healthy (per #614) on a repair or upload?

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #699

    • Property Keywords upload repair preservation added
    • Property Milestone changed from eventually to 1.7.0
    • Property Type changed from enhancement to defect
    • Property Summary changed from optionally rebalance during repair or upload to rebalance during repair or upload

  • Ticket #699 – Description

    initial v4  
    1 In [http://allmydata.org/pipermail/tahoe-dev/2009-May/001729.html this mailing list message], Humberto Ortiz-Zuazaga asks how to rebalance the shares of a file.  To close this ticket add a "rebalance" option (so, a checkbox in the WUI or a {{{--rebalance}}} flag in the CLI) that uploads new shares to any server that it thinks ought to have a share.
     1In [http://allmydata.org/pipermail/tahoe-dev/2009-May/001729.html this mailing list message], Humberto Ortiz-Zuazaga asks how to rebalance the shares of a file.  To close this ticket, ensure (either as an option or unconditionally) that repairing or uploading a file attempts to "rebalance" its shares, making it healthy as defined by #614.
    22
    33See also related tickets #481 (build some share-migration tools), #231 (good handling of small numbers of servers, or strange choice of servers), #232 (Peer selection doesn't rebalance shares on overwrite of mutable file.), and #543 ('rebalancing manager')