Opened at 2009-05-20T18:55:57Z

Last modified at 2013-05-22T05:05:48Z

#711 new enhancement

repair to different levels of N

Reported by: zooko Owned by:
Priority: major Milestone: undecided
Component: code-encoding Version: 1.4.1
Keywords: repair preservation space-efficiency newcaps research Cc:
Launchpad Bug:

Description (last modified by daira)

Currently repair will try to create a number of shares equal to whatever number the file was originally created with.

It might be useful to tell repair not to go that far and produce only a few shares.

Change History (11)

comment:1 Changed at 2009-05-20T18:56:43Z by zooko

See also #678 (converge same file, same K, different M), which if implemented would make it also be sensible to tell repair to go further and produce more shares than the original file had.

comment:2 Changed at 2009-08-10T15:28:19Z by zooko

The following clump of tickets might be of interest to people who are interested in this ticket: #711 (repair to different levels of M), #699 (optionally rebalance during repair or upload), #543 ('rebalancing manager'), #232 (Peer selection doesn't rebalance shares on overwrite of mutable file.), #678 (converge same file, same K, different M), #610 (upload should take better advantage of existing shares), #573 (Allow client to control which storage servers receive shares).

comment:3 Changed at 2009-08-10T15:45:28Z by zooko

Also related: #778 ("shares of happiness" is the wrong measure; "servers of happiness" is better).

comment:4 Changed at 2009-12-22T18:49:55Z by davidsarah

  • Keywords repair preservation added

comment:5 Changed at 2009-12-22T18:55:29Z by davidsarah

  • Keywords space-efficiency added

comment:6 Changed at 2010-07-21T16:13:43Z by zooko

  • Keywords newcaps added

comment:7 Changed at 2011-01-27T19:57:17Z by zooko

See new related ticket #1340 (consider share-at-a-time uploader).

comment:8 Changed at 2011-01-29T21:11:09Z by warner

  • Summary changed from repair to different levels of M to repair to different levels of N

s/M/N/ to match our existing "k-of-N" terminology

comment:9 Changed at 2013-01-22T14:10:08Z by zooko

  • Keywords research added

comment:10 follow-up: Changed at 2013-05-21T23:54:55Z by daira

  • Description modified (diff)

I'm confused, why would we want this? Just to decrease storage requirements?

comment:11 in reply to: ↑ 10 Changed at 2013-05-22T05:05:48Z by zooko

Replying to daira:

I'm confused, why would we want this? Just to decrease storage requirements?

So that people can change their minds about how much redundancy they want after uploading a file, and then adjust it without having to re-upload the file. If they changed their mind by reducing the desired redundancy, then great! Just let the excess shares expire or actively delete them. If they changed their mind by wanting added redundancy, then generate more shares and upload them.

Does that make sense as a desirable thing? (I'm not sure if it makes sense as a practically implementable thing...)

Note: See TracTickets for help on using tickets.