make all links as relative as possible (trac links if possible, then relative-to-trac, then server-relative)
[Imported from Trac: page FAQ, version 60]
zooko
parent
ecf3dfdf0f
commit
26b91bad28
30
FAQ.md
30
FAQ.md
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
**<a name="Q1_why_tahoe_lafs">Q1:</a> 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)?**
|
||||
**<a name="Q1_why_tahoe_lafs">Q1:</a> What is special about Tahoe-LAFS? Why should anyone care about it instead of [other distributed storage systems](RelatedProjects#OtherProjects)?**
|
||||
|
||||
A1: Tahoe-LAFS is the first Free !Software/Open Source storage technology to offer *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 [our one-page explanation](http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html).
|
||||
A1: Tahoe-LAFS is the first Free !Software/Open Source storage technology to offer *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 [//source/tahoe/trunk/docs/about.html our one-page explanation].
|
||||
|
||||
A2: Tahoe-LAFS provides reliable, fault-tolerant storage. Even if you do not need its security properties, you might want to use Tahoe-LAFS for extremely reliable storage. (Tahoe-LAFS's security features do a good job of staying out of your way when you don't need them.)
|
||||
|
||||
|
|
@ -25,19 +25,19 @@ A: There isn't currently a way to disable the encryption, but if you look at the
|
|||
|
||||
**<a name="Q4_where_are_the_docs">Q4:</a> Where should I look for current documentation about the Tahoe-LAFS protocols?**
|
||||
|
||||
A: <http://tahoe-lafs.org/source/tahoe/trunk/docs/architecture.rst>
|
||||
A: [//source/tahoe/trunk/docs/architecture.rst <https://tahoe-lafs.org/source/tahoe/trunk/docs/architecture.rst>]
|
||||
|
||||
**<a name="Q5_embedded_devices">Q5:</a> Does Tahoe-LAFS work on embedded devices such as a [PogoPlug](http://www.pogoplug.com) or an [OpenWRT](http://openwrt.org) router?**
|
||||
|
||||
A: Yes. 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 Intel SS4000-E NAS box running under Debian Squeeze. 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.
|
||||
A: Yes. François Deppierraz contributes [*buildbot-tahoe-lafs/builders/FranXois%20lenny-armv5tel a buildbot] which shows that Tahoe-LAFS builds and all the unit tests pass on his Intel SS4000-E NAS box running under Debian Squeeze. Zandr Milewski [*pipermail/tahoe-dev/2009-November/003157.html reported] that it took him only an hour to build, install, and test Tahoe-LAFS on a PogoPlug.
|
||||
|
||||
**<a name="Q6_windows">Q6:</a> Does Tahoe-LAFS work on Windows?**
|
||||
|
||||
A: Yes. Follow [the standard quickstart instructions](http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst) to get Tahoe-LAFS running on Windows. (There was also an "Allmydata Windows client", but that is not actively maintained at the moment, and relied on some components that are not open-source.)
|
||||
A: Yes. Follow [the standard quickstart instructions]source:trunk/docs/quickstart.rst to get Tahoe-LAFS running on Windows. (There was also an "Allmydata Windows client", but that is not actively maintained at the moment, and relied on some components that are not open-source.)
|
||||
|
||||
**<a name="Q7_mac_os_x">Q7:</a> Does Tahoe-LAFS work on Mac OS X?**
|
||||
|
||||
A: Yes. Follow [the standard quickstart instructions](http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst) 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.
|
||||
A: Yes. Follow [the standard quickstart instructions]source:trunk/docs/quickstart.rst 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.
|
||||
|
||||
**<a name="Q8_storage_in_multiple_dirs">Q8:</a> Can there be more than one storage directory on a storage node? So if a storage server contains 3 drives without RAID, can it use all 3 for storage?**
|
||||
|
||||
|
|
@ -124,31 +124,31 @@ A: Faruque Sarker has been working on this as a Google Summer of Code project. H
|
|||
|
||||
A: Tahoe-LAFS is designed to be unobtrusive. First of all, it doesn't start at all except when you tell it to—you start it with `tahoe start` and stop it with `tahoe stop`. Secondly, the software doesn't act as a server unless you configure it to do so—it isn't like peer-to-peer software which automatically acts as a server as well as a client. Thirdly, the client doesn't do anything except in response to the user starting an upload or a download—it doesn't do anything automatically or in the background (this might change in future, to support background repair for example, but probably only if you explicitly enable it). Fourthly, with two minor exceptions described below, the server doesn't do anything either, except in response to clients doing uploads or downloads. Finally, even when the server is actively serving clients it isn't too intensive of a process. It uses between 40 and 56 MB of RAM on a 64-bit Linux server. We used to run eight of them on a single-core 2 GHz Opteron and had plenty of CPU to spare, so it isn't too CPU intensive.
|
||||
|
||||
The two minor exceptions are that the server periodically inspects all of the ciphertext that it is storing on behalf of clients. It is configured to do this "in the background", by doing it only for a second at a time and waiting for a few seconds in between each step. The intent is that this will not noticably impact other users of the same server. For all the details about when these background processes run and what they do, read the documentation in [storage/crawler.py](http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/storage/crawler.py?annotate=blame&rev=4164) and [storage/expirer.py](http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/storage/expirer.py?annotate=blame&rev=4329).
|
||||
The two minor exceptions are that the server periodically inspects all of the ciphertext that it is storing on behalf of clients. It is configured to do this "in the background", by doing it only for a second at a time and waiting for a few seconds in between each step. The intent is that this will not noticably impact other users of the same server. For all the details about when these background processes run and what they do, read the documentation in [storage/crawler.py]source:trunk/src/allmydata/storage/crawler.py?annotate=blame&rev=4164 and [storage/expirer.py]source:trunk/src/allmydata/storage/expirer.py?annotate=blame&rev=4329.
|
||||
|
||||
|
||||
**<a name="Q19_repair">Q19:</a> If a storage server dies and new one is installed, will Tahoe-LAFS automatically generate a new share of each file to store on the new one?**
|
||||
|
||||
A: Not automatically (see also [#Q18_unobtrusive_software Q18]). There is a repair operation, but it starts only when the use triggers it, by clicking on the "repair" button on the web user interface or running the "tahoe check" command. You can, of course, execute the "tahoe check" command from a script. Kevin Reid posted [his cron script](http://tahoe-lafs.org/pipermail/tahoe-dev/2009-October/003012.html) with which he has configured his node to repair all files every night.
|
||||
A: Not automatically (see also [#Q18_unobtrusive_software Q18]). There is a repair operation, but it starts only when the use triggers it, by clicking on the "repair" button on the web user interface or running the "tahoe check" command. You can, of course, execute the "tahoe check" command from a script. Kevin Reid posted [//pipermail/tahoe-dev/2009-October/003012.html his cron script] with which he has configured his node to repair all files every night.
|
||||
|
||||
**<a name="Q20_revocation">Q20:</a> What about revoking access to a file or directory?**
|
||||
|
||||
Please see these mailing list threads:
|
||||
* [Tahoe Access Control](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006387.html)
|
||||
* [question about sharing...](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006388.html) (especially [this message by Brian Warner](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006427.html))
|
||||
* [revocation of read-access to an immutable file](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006424.html)
|
||||
* [//pipermail/tahoe-dev/2011-June/006387.html Tahoe Access Control]
|
||||
* [*pipermail/tahoe-dev/2011-June/006388.html question about sharing...] (especially [*pipermail/tahoe-dev/2011-June/006427.html this message by Brian Warner])
|
||||
* [//pipermail/tahoe-dev/2011-June/006424.html revocation of read-access to an immutable file]
|
||||
|
||||
**<a name="Q21_NAT">Q21:</a> How come sometimes my client is connected to my server even though the server is behind NAT?**
|
||||
|
||||
A:
|
||||
Ideally, all clients attempt to open connections to all servers, and all servers attempt to open connections to all clients. So, if the client is not behind NAT, then even if the server is behind NAT. However, this is not currently the case.
|
||||
**Currently** what it does is that all clients attempt to open connections to all servers, but if there is a connection between two Tahoe-LAFS processes (== Tahoe-LAFS nodes) it can re-use that connection for any client or server in either node. So, when you enable a storage server on the public facing server, that causes the node behind NAT to initiate a TCP connection to the node on the public facing server. Once that connection is established, that enables the node there to *use* the server behind NAT. Related issue: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086#comment:7>
|
||||
**Currently** what it does is that all clients attempt to open connections to all servers, but if there is a connection between two Tahoe-LAFS processes (== Tahoe-LAFS nodes) it can re-use that connection for any client or server in either node. So, when you enable a storage server on the public facing server, that causes the node behind NAT to initiate a TCP connection to the node on the public facing server. Once that connection is established, that enables the node there to *use* the server behind NAT. Related issue: [comment:119715](/tahoe-lafs/trac-2024-07-25/issues/1086#issuecomment-119715)
|
||||
|
||||
**<a name="Q22_literalcaps">Q22:</a> What are literal caps?**
|
||||
|
||||
A:
|
||||
Literal caps (or LIT caps) are simply the base32 encoding of the file data, and are used for very small files. The threshold is 55 bytes (source: [immutable/upload.py](https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/upload.py?rev=fd676a5846fce5da#L1410)), which is
|
||||
Literal caps (or LIT caps) are simply the base32 encoding of the file data, and are used for very small files. The threshold is 55 bytes (source: [immutable/upload.py]source:trunk/src/allmydata/immutable/upload.py?rev=5232#L1410), which is
|
||||
the break-even point at which the LIT filecap is the same length as a typical CHK filecap. They are sufficient (you don't even need network access to turn the LIT filecap into the data), and necessary (if you don't know the filecap for my data, you can't figure out the data). See this mailing list thread:
|
||||
* [Storing a small file leads to a weird read capability](https://tahoe-lafs.org/pipermail/tahoe-dev/2010-April/004235.html) (especially [this message by Brian Warner](https://tahoe-lafs.org/pipermail/tahoe-dev/2010-April/004237.html))
|
||||
* [*pipermail/tahoe-dev/2010-April/004235.html Storing a small file leads to a weird read capability] (especially [*pipermail/tahoe-dev/2010-April/004237.html this message by Brian Warner])
|
||||
|
||||
Literal caps are supported for immutable files and immutable directories (see [the Capabilities wiki page](https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Capabilities)). Whenever the contents of the file or directory are small enough that it would be more efficient to fit the contents into the cap itself than the store the contents remotely and use the cap to fetch it, then it becomes a literal cap.
|
||||
Literal caps are supported for immutable files and immutable directories (see [the Capabilities wiki page](Capabilities)). Whenever the contents of the file or directory are small enough that it would be more efficient to fit the contents into the cap itself than the store the contents remotely and use the cap to fetch it, then it becomes a literal cap.
|
||||
|
|
|
|||
Loading…
Reference in a new issue