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