On 01/03/12 19:21, Brian Warner wrote: > Repair strictly uses the k/N values from the uploaded file, *not* the > defaults configured into the local gateway. It needs to do this because > k and N are properties of the encoding, and are included in the filecap > (uploading the same plaintext with different k/N values will result in > different shares and different filecaps). > > That said, I don't know how our "shares of happiness" (H) value is > handled. I don't believe that H is stored in the share (whereas k and N > are definitely stored in the share).
It isn't. > I wouldn't be surprised if there's > a bug in which repair fails because it's trying to achieve a > locally-configured H value on a file that was encoded with very > different k/N values (say k=1 N=2 but H=5). That *should* fail, in the sense of reporting that the file has not been successfully repaired to the configured happiness threshold. But it should attempt to ensure that N shares have been stored on distinct servers first. I don't know whether it does that correctly. -- David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
