good handling of small numbers of servers, or strange choice of servers #213

New Issue

zooko · 2007-11-21T01:33:11Z

zooko commented

2007-11-21 01:33:11 +00:00

Suppose you try to upload something when you are on an airplane and you are
completely disconnected from all of your servers other than the one that you
yourself are running.

option 1. fail

option 2. silently upload all M shares to yourself

option 3. be transparent about this -- have output showing the user what is
happening and a knob the user can use to control to what degree you can rely
on yourself alone to store things

option 4. have a "rebalancing" operation in which data which is stored on a
"skewed" set of servers (such as too few servers, or on servers which are
less well places on the unit circle) gets moved to a more appropriate set

option 5. be transparent about that, too

Suppose you try to upload something when you are on an airplane and you are completely disconnected from all of your servers other than the one that you yourself are running. option 1. fail option 2. silently upload all M shares to yourself option 3. be transparent about this -- have output showing the user what is happening and a knob the user can use to control to what degree you can rely on yourself alone to store things option 4. have a "rebalancing" operation in which data which is stored on a "skewed" set of servers (such as too few servers, or on servers which are less well places on the unit circle) gets moved to a more appropriate set option 5. be transparent about that, too

zooko added the

labels 2007-11-21 01:33:11 +00:00

zooko added this to the eventually milestone 2007-11-21 01:33:11 +00:00

zooko commented

2007-12-17 23:49:12 +00:00

See also ticket #232 -- "peer selection doesn't rebalance shares on overwrite of mutable file".

warner commented

2007-12-18 02:08:21 +00:00

I think that silent rebalancing is going to be an important user-friendly feature. Part of the repairer's job will be to make sure the shares are distributed across a healthy set of peers, since that falls under the title of "improving the health of the file".

Providing an interface that lets the user see where their file got put is good and useful, but I don't want users to be obligated to use or pay attention to it: the abstraction of "the grid is a big place where my files go" is a valuable one, and forcing abstraction-boundary breaks adds to the user's cognitive load.

Perhaps the upload button should have a flag next to it that says "Warning: we're only connected to N peers right now, so you won't get the reliability you might expect: please consider waiting until you have more peers available" might help.

I think the general principle here is that we've (well, as least I've) been designing tahoe with a static set of peers in mind: the membership of the grid changes slowly over time. Uploading a file while you're on an airplane and then connecting to a larger grid violates this expectation.

I think that silent rebalancing is going to be an important user-friendly feature. Part of the repairer's job will be to make sure the shares are distributed across a healthy set of peers, since that falls under the title of "improving the health of the file". Providing an interface that lets the user see where their file got put is good and useful, but I don't want users to be obligated to use or pay attention to it: the abstraction of "the grid is a big place where my files go" is a valuable one, and forcing abstraction-boundary breaks adds to the user's cognitive load. Perhaps the upload button should have a flag next to it that says "Warning: we're only connected to N peers right now, so you won't get the reliability you might expect: please consider waiting until you have more peers available" might help. I think the general principle here is that we've (well, as least *I*'ve) been designing tahoe with a static set of peers in mind: the membership of the grid changes slowly over time. Uploading a file while you're on an airplane and then connecting to a larger grid violates this expectation.

zooko commented

2007-12-18 04:58:57 +00:00

As you may know, I question the value of the unbroken abstraction of "the grid is a big place where files go". I question it specifically because the cost of making it an unbroken abstraction seems high and potentially very high. On the other hand, it seems quite useful as a partial abstraction. "The grid is a big place where files go, except when it isn't for one of the following reasons..."

We don't have to agree right now on how valuable this abstraction is -- let's just agree to keep an open mind about these issues. Certainly for the two use cases that we have in mind -- the managed proprietary grid operated by sysadmins, and the friendnet -- the user (who is the sysadmin in the former case, I think), is expected to understand and monitor the state of the set of peers during normal usage.

If you mean that you aren't supposed to upload a file while you are on an airplane, and then later connect to a larger grid, because you understand that the set of servers you will be uploading to when you are on the airplane is too small, then I agree.

If you mean that people shouldn't use tahoe on machines that travel on airplanes, I'm not sure what I think about that. Certainly such portable machines should fit into the friendnet case, right? Also in the managed proprietary grid case, I should think that our semantics ought to specify some safe/useful/communicative behavior in the case that there are few servers.

As you may know, I question the value of the unbroken abstraction of "the grid is a big place where files go". I question it specifically because the cost of making it an unbroken abstraction seems high and potentially very high. On the other hand, it seems quite useful as a partial abstraction. "The grid is a big place where files go, except when it isn't for one of the following reasons..." We don't have to agree right now on how valuable this abstraction is -- let's just agree to keep an open mind about these issues. Certainly for the two use cases that we have in mind -- the managed proprietary grid operated by sysadmins, and the friendnet -- the user (who is the sysadmin in the former case, I think), is expected to understand and monitor the state of the set of peers during normal usage. If you mean that you aren't supposed to upload a file while you are on an airplane, and then later connect to a larger grid, because you understand that the set of servers you will be uploading to when you are on the airplane is too small, then I agree. If you mean that people shouldn't use tahoe on machines that travel on airplanes, I'm not sure what I think about that. Certainly such portable machines should fit into the friendnet case, right? Also in the managed proprietary grid case, I should think that our semantics ought to specify some safe/useful/communicative behavior in the case that there are few servers.

warner modified the milestone from eventually to undecided

2008-06-01 20:39:28 +00:00

warner added

code-peerselection

and removed

code-network

labels 2009-04-06 06:53:08 +00:00

USSJoin commented

2010-02-23 00:11:12 +00:00

So after some discussions today on my long-term use-case, it would seem that the same functionality set could solve this, #398, and #467. Let me explain:

I control a small number of nodes-- let's say four. I want to be able to tell my uploads that they should always leave four shares on the four nodes I own, and send the remaining six to the grid. That way, if I'm offline with only my four nodes for company, I can still use my files; similarly, when I go offline, people with access can also use my files.

In this case, I might also want to be able to configure the use of helpers etc. on a per-subnet basis; that is, "use the helper unless the node you're pushing to is on my LAN, in which case, it's silly."

Ideally I could also set up a modified rebalancer that says "make four shares and put them on my local grid subset," but that's secondary.

So after some discussions today on my long-term use-case, it would seem that the same functionality set could solve this, #398, and #467. Let me explain: I control a small number of nodes-- let's say four. I want to be able to tell my uploads that they should always leave four shares on the four nodes *I* own, and send the remaining six to the grid. That way, if I'm offline with *only* my four nodes for company, I can still use my files; similarly, when I go offline, people with access can *also* use my files. In this case, I might also want to be able to configure the use of helpers etc. on a per-subnet basis; that is, "use the helper unless the node you're pushing to is on my LAN, in which case, it's silly." Ideally I could also set up a modified rebalancer that says "make four shares and put them on my local grid subset," but that's secondary.

tahoe-lafs added

1.6.0

and removed

0.7.0

labels 2010-02-23 00:11:12 +00:00

zooko commented

2010-12-29 14:44:56 +00:00

There's some good discussion in this ticket, but I think all of the changes we might make are covered by #778, #398, and #467. I'm closing this one as a duplicate and putting a reference to this one into #398 and #467.