tahoe-lafs/trac-2024-07-25

repair to different levels of N #711

New issue

Open

opened 2009-05-20 18:55:57 +00:00 by zooko · 7 comments

zooko commented

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

Owner

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.

tahoe-lafs added the

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

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

zooko commented

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

Author

Owner

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

Author

Owner

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

Author

Owner

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

Author

Owner

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

warner commented

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

Author

Owner

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

tahoe-lafs 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

Author

Owner

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

zooko commented

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

Author

Owner

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