tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

boldify the questions 

[Imported from Trac: page FAQ, version 22]
terrell 2010-07-01 14:45:02 +00:00
parent 7a5a6b9d40
commit 29a78a2a2a
1 changed files with 15 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
FAQ.md

@ -1,26 +1,26 @@
Q: What is special about Tahoe-LAFS? Why should anyone care about it instead of [other distributed storage systems](http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects#OtherProjects)?
**Q: What is special about Tahoe-LAFS? Why should anyone care about it instead of [other distributed storage systems](http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects#OtherProjects)?**
A1: Tahoe-LAFS is the first Free !Software/Open Source storage technology which offers *provider-independent security*. *Provider-independent security* means that the integrity and confidentiality of your files is guaranteed by mathematics computed on the client side, and is independent of the servers, which may be owned and operated by someone else. To learn more, read [.org/source/tahoe/trunk/docs/about.html our one-page explanation](http://tahoe-lafs).
A2: Tahoe-LAFS is an extremely reliable, distributed, fault-tolerant storage system. Even if you do not need its security properties, you might want to use Tahoe-LAFS as a very robust and flexible storage platform. (Tahoe-LAFS's security features do an excellent job of staying out of your way when you don't need them.)
Q: "Erasure-coding"? What's that?
**Q: "Erasure-coding"? What's that?**
A: You know how with RAID-5 you can lose any one drive and still recover? And there is also something called RAID-6 where you can lose any two drives and still recover. Erasure coding is the generalization of this pattern: you get to configure it for how many drives you could lose and still recover. Tahoe-LAFS is typically configured to upload each file to 10 different drives, where you can lose any 7 of them and still recover the entire file. This gives radically better reliability than typical RAID setups, at a cost of only 3.3 times the storage space that a single copy takes. (This technique is also known as "forward error correction" and as an "information dispersal algorithm".)
Q: Is there a way to disable the encryption phase and just use the encoding on the actual content? Won't that save a lot of CPU cycles?
**Q: Is there a way to disable the encryption phase and just use the encoding on the actual content? Won't that save a lot of CPU cycles?**
A: There isn't currently a way to disable or skip the encryption phase, but if you watch the status page on your local tahoe-lafs node for uploads, you'll see that the encryption time is orders (yes, plural) of magnitude smaller than the upload time, so there isn't much performance to be gained by skipping the encryption. We prefer 'secure by default', so without a compelling reason to allow insecure operation, our plan is to leave encryption turned on all the time.
Q: Where should I look for current documentation about Tahoe's protocols?
**Q: Where should I look for current documentation about Tahoe's protocols?**
A: <http://tahoe-lafs.org/source/tahoe/trunk/docs/architecture.txt>
Q: Does Tahoe-LAFS work on embedded devices such as a [PogoPlug](http://www.pogoplug.com) or an [OpenWRT](http://openwrt.org) router?
**Q: Does Tahoe-LAFS work on embedded devices such as a [PogoPlug](http://www.pogoplug.com) or an [OpenWRT](http://openwrt.org) router?**
A: Probably! François Deppierraz contributes [a buildbot](http://tahoe-lafs.org/buildbot/builders/FranXois%20lenny-armv5tel) which shows that Tahoe-LAFS builds and all the unit tests pass on his QNAP TS-109 NAS box running under Debian Lenny. There seems to be a lot of interest in this sort of deployment -- someone joins the mailing list and asks about this approximately every month (see [the archives](http://tahoe-lafs.org/pipermail/tahoe-dev/)). Zandr Milewski [reported](http://tahoe-lafs.org/pipermail/tahoe-dev/2009-November/003157.html) that it took him only an hour to build, install, and test Tahoe-LAFS on a PogoPlug.
Q: Does Tahoe-LAFS work on Windows?
**Q: Does Tahoe-LAFS work on Windows?**
A: Yes. There are two ways to do it:
@ -29,15 +29,15 @@ either
or else
2. Follow [the standard quickstart instructions](http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html) to get Tahoe-LAFS running on Windows.
Q: Does Tahoe-LAFS work on Mac OS X?
**Q: Does Tahoe-LAFS work on Mac OS X?**
A: Yes. Follow [the standard quickstart instructions](http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html) on Mac OS X and it will result in a working command-line tool on Mac OS X just as it does on other Unixes. (This includes the Web User Interface, or "WUI". See the instructions for details.) In addition there is code to generate executables and .dmg packages, but this code is not currently working (as of Tahoe-LAFS v1.6.1). See the "mac" targets [in the Makefile]source:Makefile@#L440.
Q: Can there be more than one storage folder on a storage node? So if a storage server contains 3 drives without RAID, can it use all 3 for storage?
**Q: Can there be more than one storage folder on a storage node? So if a storage server contains 3 drives without RAID, can it use all 3 for storage?**
A: Not directly. Each storage server has a single "base directory" which we abbreviate as $BASEDIR. The server keeps all of its shares in a subdirectory named $BASEDIR/storage/shares/ . (Note that you can symlink this to whatever you want: you can run most of the node from one place, and store all the shares somewhere else). Since there's only one such subdirectory, you can only use one filesystem per node.On the other hand, shares are stored in a set of 1024 subdirectories of that one, named $BASEDIR/storage/shares/aa/, $BASEDIR/storage/shares/ab/, etc. If you were to symlink the first third of these to one filesystem, the next third to a second filesystem, etc, (hopefully with a script!), then you'd get about 1/3rd of the shares stored on each disk. The "how much space is available" and space-reservation tools would be confused, but basically everything else should work normally.
Q: Would it make sense to just use RAID-0 and let Tahoe-LAFS deal with the redundancy?
**Q: Would it make sense to just use RAID-0 and let Tahoe-LAFS deal with the redundancy?**
A: The Allmydata grid didn't bother with RAID at all: each Tahoe storage server node used a single spindle.
The "RAID and/or Tahoe" question depends upon how much you trust RAID vs how much you trust Tahoe, and how expensive the different forms of
@ -65,8 +65,8 @@ read/write performance, and probability of file loss due to failures happening f
In addition, Tahoe's current repair code is not particularly clever: it doesn't put the new shares in exactly the right places, so you can
easily get shares doubled up and not distributed as evenly as if you'd done a single upload. This is being tracked in ticket #610.
Q: Suppose I have a file of 100GB and 2 storage nodes each with 75GB available, will I be able to store the file or does it have to fit
within the realms of a single node?
'''Q: Suppose I have a file of 100GB and 2 storage nodes each with 75GB available, will I be able to store the file or does it have to fit
within the realms of a single node?'''
A: The ability to store the file will depend upon how you set the encoding parameters: you get to choose the tradeoff between expansion (how much
space gets used) and reliability. The default settings are "3-of-10" (very conservative), which means the file is encoded into 10 shares, and
@ -82,7 +82,7 @@ either server being down (since neither server has enough shares to give you the
individual share (if only one share file were damaged, there are still five other shares, and we only need four). A lot of disk errors affect
only a single file, so there's some benefit to this even if you're still vulnerable to a full disk/server failure.
Q: Do I need to shutdown all clients/servers to add a storage node?
**Q: Do I need to shutdown all clients/servers to add a storage node?**
A: No, You can add or remove clients or servers anytime you like. The central "Introducer" is responsible for telling clients and servers
about each other, and it acts as a simple publish-subscribe hub, so everything is very dynamic. Clients re-evaluate the list of available
@ -95,8 +95,8 @@ of a client-side configuration statement that lists all the servers that you exp
connected to at least those). A list like that might require a client restart when you wanted to add to this "required" list, but we could
implement such a feature without a restart requirement too.
Q: If I had 3 locations each with 5 storage nodes, could I configure the grid to ensure a file is written to each location so that I could handle all
servers at a particular location going down?
'''Q: If I had 3 locations each with 5 storage nodes, could I configure the grid to ensure a file is written to each location so that I could handle all
servers at a particular location going down?'''
A: Not directly. We have a ticket about that one (#467, #302), but it's deeper than it looks and we haven't come to a conclusion on how to
build it.
@ -125,9 +125,7 @@ sum = 3003<br>
So you've got a 50% chance of the ideal distribution, and a 1/1000 chance of the worst-case distribution.
Q: Is it possible to modify a mutable file by "patching" it?
So, if I have a file stored and I want to update a section of the file in the middle, is that possible or would be file need to be downloaded,
patched and re-uploaded?
**Q: Is it possible to modify a mutable file by "patching" it? Also... if I have a file stored and I want to update a section of the file in the middle, is that possible or would be file need to be downloaded, patched and re-uploaded?**
A: Not at present. We've only implemented "Small Distributed Mutable Files" (SDMF) so far, which have the property that the whole file must be
downloaded or uploaded at once. We have plans for "medium" MDMF files, which will fix this. MDMF files are broken into segments (default size