| 1 | | When a storage server receives a {{{remote_get_buckets}}} or {{{remote_slot_testv_and_readv_and_writev}}} request, it will try to create share objects for each of the shares it stores under that SI that are wanted by the client. If any of those shares have a corrupt header (typically resulting in a {{{UnknownMutableContainerVersionError}}}, {{{UnknownImmutableContainerVersionError}}}, or {{{struct.error}}} from the share class constructor), the whole request will fail, even though the server might hold other shares that are not corrupted. |
| 2 | | |
| 3 | | Unfortunately there is no way in the current storage protocol to report success for some shares and a failure for others. The options are: |
| 4 | | * the status quo -- no shares in the shareset are accessible; |
| 5 | | * shares with corrupt headers are ignored on read requests; |
| 6 | | * if ''all'' shares are corrupted then report one of the errors, but if only some shares in a shareset have corrupted headers, ignore them and allow access to the rest. |
| 7 | | |
| 8 | | I found this bug when working on the branch for #999, but I think it also applies to trunk. I will write a test. |
| | 1 | [posted description as a comment by mistake] |
