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

New Issue

tahoe-lafs · 2010-07-13T21:04:53Z

kevan commented

2010-07-13 21:04:53 +00:00

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 [//pipermail/tahoe-dev/2010-July/004656.html https://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004656.html])

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 [//pipermail/tahoe-dev/2010-July/004656.html <https://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004656.html>])

tahoe-lafs added the

labels 2010-07-13 21:04:53 +00:00

tahoe-lafs added this to the 1.7.1 milestone 2010-07-13 21:04:53 +00:00

zooko commented

2010-07-14 06:37:38 +00:00

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.

tahoe-lafs modified the milestone from 1.7.1 to 1.8β

2010-07-18 02:36:18 +00:00

tahoe-lafs modified the milestone from 1.8β to soon

2010-09-11 00:56:17 +00:00

tahoe-lafs modified the milestone from soon to 1.11.0

2013-09-01 05:29:31 +00:00

zooko commented

2013-09-01 14:10:07 +00:00

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]source:trunk/src/allmydata/immutable/upload.py?annotate=blame&rev=196bd583b6c4959c60d3f73cdcefc9edda6a38ae 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"?

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]source:trunk/src/allmydata/immutable/upload.py?annotate=blame&rev=196bd583b6c4959c60d3f73cdcefc9edda6a38ae 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"?

zooko changed title 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

2013-09-01 14:10:07 +00:00

tahoe-lafs modified the milestone from 1.11.0 to 1.12.0

2013-09-01 19:16:36 +00:00

zooko commented

2013-12-05 16:56:41 +00:00

related ticket: #2101