f11769560c
Many of the test cases would exercise two copies of each file: one with
k=3/N=10, and a second with k=127/N=255 (255 being the maximum supported
by zfec).
Large number of shares increases the overhead of the testing apparatus,
which is pushing those shares to lots of local servers.
I don't think the "max_shares" case is necessary, and it takes forever.
Because of it, "mutable.Update" was consuming 15% of the total test
runtime, and a third of that was just a single
function (test_replace_locations_max_shares, now deleted). On a
Raspberry Pi 3 (our "slow computer" benchmark), including branch
coverage, this one class took 42 minutes to complete, and requires
disabling a bunch of timeouts to finish at all.
The total number of shares in a file ("N") affects one thing: the
width (and thus height) of the share hash tree. This should be exercised
in test_hashtree.
The number of required shares ("k") affects one thing: the segment size
must be a multiple of k. I don't think we need to exercise this, but if
so, it could be exercised by a few small values for k, rather than 127.
Removing the max_shares cases saves 82% of the mutable.update
runtime (on top of the previous three-segment fix), reducing it from 64s
to 11.3s on my laptop.
|
||
|---|---|---|
| docs | ||
| misc | ||
| src/allmydata | ||
| static | ||
| topfiles | ||
| .appveyor.yml | ||
| .coveragerc | ||
| .gitignore | ||
| .travis.yml | ||
| COPYING.GPL | ||
| COPYING.TGPPL.rst | ||
| CREDITS | ||
| Dockerfile | ||
| Makefile | ||
| MANIFEST.in | ||
| NEWS.rst | ||
| README.rst | ||
| relnotes.txt | ||
| setup.cfg | ||
| setup.py | ||
| Tahoe.home | ||
| tox.ini | ||
Tahoe-LAFS
Tahoe-LAFS is a Free and Open decentralized cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire file store continues to function correctly, preserving your privacy and security.
For full documentation, please see http://tahoe-lafs.readthedocs.io/en/latest/ .
INSTALLING
Pre-packaged versions are available for several operating systems:
- Debian and Ubuntu users can
apt-get install tahoe-lafs - NixOS, NetBSD (pkgsrc), ArchLinux, Slackware, and Gentoo have packages available, see OSPackages for details
- Mac and Windows installers are in development.
If you don't use an OS package, you'll need Python 2.7 and pip. You may also need a C compiler, and the development headers for python, libffi, and OpenSSL. On a Debian-like system, use apt-get install build-essential python-dev libffi-dev libssl-dev python-virtualenv. On Windows, see docs/windows.rst.
Then, to install the most recent release, just run:
pip install tahoe-lafs
To install from source (either so you can hack on it, or just to run pre-release code), you should create a virtualenv and install into that:
git clone https://github.com/tahoe-lafs/tahoe-lafs.gitcd tahoe-lafsvirtualenv venvvenv/bin/pip install --editable .venv/bin/tahoe --version
To run the unit test suite:
tox
For more detailed instructions, read docs/INSTALL.rst .
Once tahoe --version works, see docs/running.rst to learn how to set up your first Tahoe-LAFS node.
LICENCE
Copyright 2006-2016 The Tahoe-LAFS Software Foundation
You may use this package under the GNU General Public License, version 2 or, at your option, any later version. You may use this package under the Transitive Grace Period Public Licence, version 1.0, or at your option, any later version. (You may choose to use this package under the terms of either licence, at your option.) See the file COPYING.GPL for the terms of the GNU General Public License, version 2. See the file COPYING.TGPPL for the terms of the Transitive Grace Period Public Licence, version 1.0.
See TGPPL.PDF for why the TGPPL exists, graphically illustrated on three slides.