Opened at 2011-01-05T03:27:55Z
Last modified at 2021-03-30T18:40:19Z
#1293 assigned defect
servers-of-happiness is too conservative when K = 1
Reported by: | davidsarah | Owned by: | davidsarah |
---|---|---|---|
Priority: | major | Milestone: | soon |
Component: | code | Version: | 1.8.1 |
Keywords: | servers-of-happiness usability availability unfinished-business | Cc: | |
Launchpad Bug: |
Description (last modified by markberger)
When K = 1, any single share is sufficient to reconstruct the file. However, the servers-of-happiness code will still require that there are H servers with unique share numbers. It should not care about the share numbers.
(We knew of examples with small K where the maximum matching definition of servers-of-happiness was conservative relative to the original definition, e.g. 778#comment:198. However, for K > 1 it is more space-efficient to use the maximum matching definition. For K = 1 it is not.)
Change History (9)
comment:1 Changed at 2011-01-06T00:32:21Z by davidsarah
- Milestone changed from 1.9.0 to 1.8.2
- Owner changed from somebody to davidsarah
- Status changed from new to assigned
comment:2 Changed at 2011-01-18T08:25:28Z by zooko
- Milestone changed from 1.8.2 to 1.9.0
comment:3 Changed at 2011-07-24T22:42:30Z by davidsarah
- Milestone changed from 1.9.0 to 1.10.0
It makes sense to fix this at the same time as Kevan's changes to share placement behaviour in #1382, which will not be in 1.9.
comment:4 Changed at 2013-08-28T15:19:13Z by markberger
- Description modified (diff)
For example, if we have a share distribution like this:
- Server A: [1]
- Server B: [1]
- Server C: [1]
with k = 1 and h = 3, the placement will be considered unhealthy even though we don't care about the share numbers because any single share is sufficient to reconstruct the file.
comment:5 Changed at 2013-08-28T15:22:48Z by daira
- Keywords unfinished-business added
- Milestone changed from 1.11.0 to 1.12.0
comment:6 Changed at 2016-03-22T05:02:25Z by warner
- Milestone changed from 1.12.0 to 1.13.0
Milestone renamed
comment:7 Changed at 2016-06-28T18:17:14Z by warner
- Milestone changed from 1.13.0 to 1.14.0
renaming milestone
comment:8 Changed at 2020-06-30T14:45:13Z by exarkun
- Milestone changed from 1.14.0 to 1.15.0
Moving open issues out of closed milestones.
comment:9 Changed at 2021-03-30T18:40:19Z by meejah
- Milestone changed from 1.15.0 to soon
Ticket retargeted after milestone closed
I think we're out of time for 1.8.2. (Apologies if you're actually still intending to do this for 1.8.2.)