I'm not sure whether I'm misunderstanding something, or whether I've found a bug.
I've been playing with my home grid a lot recently. When I first set up this grid I was using encoding parameters 2/3/4 but I changed this to 2/4/4 after the first couple days. When I filed ticket #1130 I believed I was running into some kind of interference from the fact that I had previously been using 2/3/4, and was just hitting a problem in changing my encoding parameters -- which most people probably don't do. I needed a workaround, so I thought of one. Since I wanted to use 2/4/4, shares.happy == shares.total, and I had exactly 4 storage nodes in my grid, so I reasoned that I should expect every storage node to get exactly one share. My workaround was to write a script that I ran on each storage node. The script identified storage indexes with more than one share, and deleted those storage indexes. Firstly, was my workaround correct, at least in principle? (It sure seemed to be effective in practice.) I'm writing now with an unsettling observation. The upload errors eventually came back, and if I re-run the script it again identifies storage indexes with more than one share! Shouldn't that be impossible? I'm consistently running with 2/4/4 now, so shouldn't every storage index always have exactly one share? Does this suggest that there's (still) a bug in share placement that causes unreported happiness failures? Or might I still somehow be seeing some kind of leftover from my 2/3/4 encoding days? -- Kyle Markley _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
