On 3/1/12 4:03 PM, David-Sarah Hopwood wrote: > On 01/03/12 19:21, Brian Warner wrote:
>> 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. Hrm, I get it, but that's going to cause confusion. Sometimes repair succeeds, sometimes it fails, the only difference being the repairing node's default settings, most of which (k/N) never matter. I suppose it's highlighting the question/uncertainty of how much the file is defined by the original uploader, and how much it's defined by the node doing the repair. I guess I'm inclined to think that H should be stored in the share and respected by the repairer, rather than saying that repair has failed because the repairer's notion of Happy is more stringent than the original uploaders. OTOH, I can see arguments for the other direction too. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
