ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-23 23:02:25 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

NEWS: minor edits

Browse Source
This commit is contained in:
Brian Warner 2008-11-06 16:33:56 -07:00
parent 0b552da5fc
commit 4982995f07
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
NEWS
View File

@ -9,7 +9,7 @@ usability of code which checks/verifies/repairs files and directories.
"Checking" is the act of asking storage servers whether they have a share for
the given file or directory: if there are not enough shares available, the
file/directory will be unrecoverable. "Verifying" is the act of downloading
or cryptographically asserting that the server's share is undamaged: it
and/or cryptographically asserting that the server's share is undamaged: it
requires more work (bandwidth and CPU) than checking, but can catch problems
that simple checking cannot. "Repair" is the act of replacing missing/damaged
shares with new ones.
@ -24,7 +24,7 @@ together to remove the damaged share. Note that corrupted shares indicate
hardware failures, serious software bugs, or malice on the part of the
storage server operator, so a corrupted share should be considered highly
unusual. The "incident gatherer" mechanism will automatically report share
corruption to an incident gatherer service, if one is pre-configured.
corruption to an incident gatherer service, if one is configured.
By periodically checking/repairing all files and directories, objects in the
Tahoe filesystem remain resistant to recoverability failures due to missing
@ -46,7 +46,7 @@ and deep-check operations. When these operations finish, they display a
results page that summarizes any problems that were encountered. All
long-running deep-traversal operations, including deep-check, use a
start-and-poll mechanism, to avoid depending upon a single long-lived HTTP
connection. docs/webapi.txt has details.
connection. docs/frontends/webapi.txt has details.
** Configuration Changes: single INI-format tahoe.cfg file
@ -66,7 +66,7 @@ timeouts (#521).
This release adds the 'tahoe create-alias' command, which is a combination of
'tahoe mkdir' and 'tahoe add-alias'. This also allows you to start using a
new tahoe directory without exposing its URI in the argv list, which is
publically visible (through the process table) on most unix systems.
publicly visible (through the process table) on most unix systems.
The single-argument form of "tahoe put" was changed to create an unlinked
file. I.e. "tahoe put bar.txt" will take the contents of a local "bar.txt"
@ -278,11 +278,11 @@ The 12GiB (approximate) immutable-file-size limitation is slowly being
lifted. This release knows how to handle so-called "v2 immutable shares",
which permit immutable files of up to about 18 EiB (about 3*10^14). These v2
shares are not yet created by default, so that files created with tahoe-1.3.0
can still be read by earlier versions. In the subsequent release we will
switch to generating v2 shares, so that files created with tahoe-1.4.0 can be
read by tahoe-1.3.0 and later. Note that the storage server must also be
changed to support files larger than 12GiB, and that these changes have not
yet been implemented. (ticket #346)
can still be read by earlier versions. In the next release we will switch to
generating v2 shares, so that files created with tahoe-1.4.0 can be read by
tahoe-1.3.0 and later. Note that the storage server must also be changed to
support files larger than 12GiB, and that these changes have not yet been
implemented. (ticket #346)
Tahoe now uses Foolscap "Incidents", writing an "incident report" file to
logs/incidents/ each time something weird occurs. These reports are available
@ -297,10 +297,10 @@ These reports are written to files in BASEDIR/storage/corruption-advisories .
The 'nickname' setting is now defined to be a UTF-8 -encoded string, allowing
non-ascii nicknames.
The 'tahoe start' command will now pass a --syslog argument through to
twistd, making it easier to launch non-Tahoe nodes (like the cpu-watcher) and
have them log to syslogd instead of a local file. This is useful when running
a Tahoe node out of a USB flash drive.
The 'tahoe start' command will now accept a --syslog argument and pass it
through to twistd, making it easier to launch non-Tahoe nodes (like the
cpu-watcher) and have them log to syslogd instead of a local file. This is
useful when running a Tahoe node out of a USB flash drive.
Tahoe now includes experimental FTP and SFTP servers. When configured with a
suitable method to translate username+password into a root directory cap, it