[tahoe-dev] [tahoe-lafs] #1212: Repairing fails if less than 7 servers available
tahoe-lafs
trac at tahoe-lafs.org
Thu Oct 14 04:53:40 UTC 2010
#1212: Repairing fails if less than 7 servers available
------------------------------+---------------------------------------------
Reporter: eurekafag | Owner:
Type: defect | Status: reopened
Priority: major | Milestone: 1.8.1
Component: code-network | Version: 1.8.0
Resolution: | Keywords: reviewed regression repair
Launchpad Bug: |
------------------------------+---------------------------------------------
Comment (by zooko):
One possibility would be to make the behavior of uploader different than
of repairer. Perhaps people prefer for their initial uploads to fail
quickly and network-efficiently (principle 3) if they won't be able to
achieve happiness level of {{{H}}}, but prefer for their repairs to
proceed and do their best (principle 2). However, making the two behave
differently would make things more complicated in the source code and
would also make things more complicated in the usage, because principle 1
-- ''idempotence'' -- would not apply to "first upload and then repair" or
"first repair and then upload". Sometimes an upload would abort itself and
return failure but then a subsequent repair would do a lot of work to make
progress, or a repair would do a lot of work to make progress but then an
upload would abort itself and return failure.
Unless we are really sure that we need to support two different modes, I
would prefer to err on the side of simplicity and find a mode that is good
enough for both upload and repair. One good way to estimate "complication
in usage" is to think how much documentation we would need to write to
explain the different behavior of upload and repair in the different
cases. :-)
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1212#comment:27>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-dev
mailing list