Context Navigation

← Previous Ticket
Next Ticket →

Opened at 2010-07-13T21:04:53Z

Last modified at 2021-03-30T18:40:19Z

#1116 new defect

clarify difference between full and read-only servers in servers-of-happiness failure message

Reported by:	kevan	Owned by:	daira
Priority:	major	Milestone:	soon
Component:	code-peerselection	Version:	1.7.0
Keywords:	easy unfinished-business usability error servers-of-happiness upload	Cc:
Launchpad Bug:

Description (last modified by zooko)

When it fails to find a satisfactory share layout, the peer selection process for immutable files prints out a message explaining why. In that, it counts servers that did not accept shares that they were asked to as full. This is slightly confusing, since the servers may not be full, but instead may just have too little free space to accept shares of the size it was asked to accept. The error message should be changed to reflect this.

(this was first reported in https://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004656.html)

Change History (16)

comment:1 Changed at 2010-07-13T21:05:05Z by kevan

Owner set to kevan

comment:2 Changed at 2010-07-14T06:37:38Z by zooko

Keywords unfinished-business added

I just made up a tag "unfinished-business" to mean an issue that is in some sense caused by a recent change even though the issue is not really a regression. Maybe in the morning inventing this tag will seem like a bad idea, but then we can always delete it and never speak of it again.

comment:3 Changed at 2010-07-18T02:36:18Z by davidsarah

Milestone changed from 1.7.1 to 1.8β

comment:4 Changed at 2010-07-20T03:51:17Z by davidsarah

Keywords usability error added

comment:5 Changed at 2010-09-11T00:56:17Z by davidsarah

Milestone changed from 1.8β to soon

comment:6 Changed at 2010-12-29T09:15:32Z by zooko

Keywords servers-of-happiness added

comment:7 Changed at 2010-12-29T09:19:01Z by zooko

Keywords upload added

comment:8 Changed at 2013-09-01T05:29:31Z by daira

Description modified (diff)
Milestone changed from soon to 1.11.0

comment:9 Changed at 2013-09-01T13:46:55Z by zooko

Description modified (diff)

comment:10 Changed at 2013-09-01T14:10:07Z by zooko

Owner changed from kevan to daira
Summary changed from make the servers-of-happiness error message less confusing to clarify difference between full and read-only servers in servers-of-happiness failure message

I just read through the mailing list thread and the relevant source code.

I believe the original issue report was mistaken, but there is still something confusing in this error message that should be clarified.

The original report from Kyle Markley on the mailing list turned out to have a different error behind it — #1118. Kevan opened this ticket in the belief that Kyle was confused about the difference between a server being "full" and being "not quite full, but too full to accept that share there", but Kyle was not confused about that.

I read through the source just now, and servers get counted as "full" by the uploader if either:

a) They are read-only, the uploader queries them to see if they have a share, and they respond with something other than a failure, or

b) They are not read-only, the uploader asks them to store one or more shares, and they store zero shares.

I'm pretty sure that the current server will do b) only in the case that it is full.

So I think the error message is already pretty accurate, except that it is combining full servers and read-only servers into one number. To close this ticket, track full servers (currently tracked in a member variable named full_count in the code separately from read-only servers, and change the error message from "of which %d placed none due to the server being full" to something like "of which %d placed none due to the server being full and %d found none already present on a read-only server".

I don't think this ticket belongs in Milestone 1.11! Daira: could we move this to "soon"?