repair to different levels of N #711

New Issue

zooko · 2009-05-20T18:55:57Z

zooko commented

2009-05-20 18:55:57 +00:00

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.

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.

zooko added the

labels 2009-05-20 18:55:57 +00:00

zooko added this to the undecided milestone 2009-05-20 18:55:57 +00:00

zooko commented

2009-05-20 18:56:43 +00:00

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.

zooko commented

2009-08-10 15:28:19 +00:00

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).

zooko commented

2009-08-10 15:45:28 +00:00

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

zooko commented

2011-01-27 19:57:17 +00:00

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

warner commented

2011-01-29 21:11:09 +00:00

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

warner changed title from ~~repair to different levels of M~~ to repair to different levels of N

2011-01-29 21:11:09 +00:00

daira commented

2013-05-21 23:54:55 +00:00

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

zooko commented

2013-05-22 05:05:48 +00:00

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...)

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/711#issuecomment-71230): > 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...)

Sign in to join this conversation.