[tahoe-dev] Upload misunderstanding or bug?

[Greg Troxel]

Kyle Markley <kyle at arbyte.us> writes:

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

One thing that I'm not 100% clear on: I think the 2/3/4 params may be
encoded in the URI, and changing the config only affects the creation of
new objects.  If what you really want is to change the rules for the
root directory, you might need to 'cp -r' and repoint your root.

It would be nice if the command-line 'tahoe check' could print out more
info about this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100728/87b49f6e/attachment.pgp>