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

More comprehensive changes and ticket references for NEWS

Browse Source
This commit is contained in:
david-sarah 2010-02-01 22:12:56 -08:00
parent 4d2c81d009
commit 210afd3e9e
1 changed files with 42 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
NEWS
View File

@ -6,14 +6,15 @@ User visible changes in Tahoe-LAFS. -*- outline -*-
*** Immutable Directories
Tahoe-LAFS can now create and handle immutable directories (#607). These are
read just like normal directories, but are "deep-immutable", meaning that all
their children (and everything reachable from those children) must be immutable
objects (i.e. immutable/literal files, and other immutable directories).
Tahoe-LAFS can now create and handle immutable directories. (#607, #833, #931)
These are read just like normal directories, but are "deep-immutable", meaning
that all their children (and everything reachable from those children) must be
immutable objects (i.e. immutable or literal files, and other immutable
directories).
These directories must be created in a single webapi call, which provides all
of the children at once (instead of the usual create/add/add sequence, since
they cannot be changed after creation). They have URIs that start with
These directories must be created in a single webapi call that provides all
of the children at once. (Since they cannot be changed after creation, the
usual create/add/add sequence cannot be used.) They have URIs that start with
"URI:DIR2-CHK:" or "URI:DIR2-LIT:", and are described on the human-facing web
interface (aka the "WUI") with a "DIR-IMM" abbreviation (as opposed to "DIR"
for the usual read-write directories and "DIR-RO" for read-only directories).
@ -34,17 +35,17 @@ The "tahoe backup" command has been enhanced to create immutable directories
(in previous releases, it created read-only mutable directories) (#828). This
is significantly faster, since it does not need to create an RSA keypair for
each new directory. Also "DIR-IMM" immutable directories are repairable, unlike
"DIR-RO" read-only mutable directories (at least in this release: a future
Tahoe-LAFS release should be able to repair DIR-RO).
"DIR-RO" read-only mutable directories at present. (A future Tahoe-LAFS release
should also be able to repair DIR-RO.)
In addition, the backupdb (used by "tahoe backup" to remember what it has
already copied) has been enhanced to store information about existing immutable
directories. This allows it to re-use directories that have moved but still
contain identical contents, or which have been deleted and later replaced. (the
contain identical contents, or that have been deleted and later replaced. (The
1.5.0 "tahoe backup" command could only re-use directories that were in the
same place as they were in the immediately previous backup). With this change,
same place as they were in the immediately previous backup.) With this change,
the backup process no longer needs to read the previous snapshot out of the
Tahoe-LAFS grid, reducing the network load considerably.
Tahoe-LAFS grid, reducing the network load considerably. (#606)
A "null backup" (in which nothing has changed since the previous backup) will
require only two Tahoe-side operations: one to add an Archives/$TIMESTAMP
@ -59,8 +60,9 @@ had to be uploaded too): it will require time proportional to the number and
size of your directories. After this initial pass, all subsequent passes
should take a tiny fraction of the time.
As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot read immutable
directories.
As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot list a directory
containing an immutable subdirectory. Tahoe-LAFS versions earlier than 1.6.0
cannot read the contents of an immutable directory.
The "tahoe backup" command has been improved to skip over unreadable objects
(like device files, named pipes, and files with permissions that prevent the
@ -75,10 +77,10 @@ The basic idea behind Tahoe-LAFS's client+server and client-only processes is
that you are creating a general-purpose Tahoe-LAFS "node" process, which has
several components that can be activated. Storage service is one of these
optional components, as is the Helper, FTP server, and SFTP server. Web gateway
functionality is nominally on this list, but it is always active: a future
functionality is nominally on this list, but it is always active; a future
release will make it optional. There are three special purpose servers that
can't currently be run as a component in a node: introducer, key-generator,
stats-gatherer.
and stats-gatherer.
So now "tahoe create-node" will create a Tahoe-LAFS node process, and after
creation you can edit its tahoe.cfg to enable or disable the desired
@ -91,13 +93,13 @@ service. (#760)
storage service. It is equivalent to "tahoe create-node --no-storage". This
helps to reduce the confusion surrounding the use of a command with "client" in
its name to create a storage *server*. Use "tahoe create-client" to create a
purely client-side node. If you want to offer storage to the grid, use "tahoe
create-node" instead.
purely client-side node. If you want to offer storage to the grid, use
"tahoe create-node" instead.
In the future, other services will be added to the node, and they will be
controlled through options in tahoe.cfg . The most important of these services
may get additional --enable-XYZ or --disable-XYZ arguments to "tahoe
create-node".
controlled through options in tahoe.cfg . The most important of these
services may get additional --enable-XYZ or --disable-XYZ arguments to
"tahoe create-node".
** Performance Improvements
@ -112,8 +114,8 @@ any K shares are located. This means that downloads start sooner, which is
particularly important if there is a server on the grid that is extremely slow
or even hung in such a way that it will never respond. In previous releases
such a server would have a negative impact on all downloads from that grid. In
this release, such a server will have no impact on downloads (as long as K
shares can be found on other, quicker, servers.) This also means that
this release, such a server will have no impact on downloads, as long as K
shares can be found on other, quicker, servers. This also means that
downloads now use the "best-alacrity" servers that they talk to, as measured by
how quickly the servers reply to the initial query. This might cause downloads
to go faster, especially on grids with heterogeneous servers or geographical
@ -124,19 +126,19 @@ dispersion.
The webapi acquired a new "t=mkdir-with-children" command, to create and
populate a directory in a single call. This is significantly faster than
using separate "t=mkdir" and "t=set-children" operations (it uses one
gateway-to-grid roundtrip, instead of three or four).
gateway-to-grid roundtrip, instead of three or four). (#533)
The t=set-children (note the hyphen) operation is now documented in
docs/frontends/webapi.txt, and is the new preferred spelling of the old
t=set_children (with an underscore). The underscore version remains for
backwards compatibility.
backwards compatibility. (#381, #927)
The tracebacks produced by errors in CLI tools should now be in plain text,
instead of HTML (which is unreadable outside of a browser). (#646)
The [storage]reserved_space configuration knob (which causes the storage
server to refuse shares when available disk space drops below a threshold)
should work on windows now, not just unix. (#637)
should work on Windows now, not just UNIX. (#637)
"tahoe cp" should now exit with status "1" if it cannot figure out a suitable
target filename, such as when you copy from a bare filecap. (#761)
@ -148,6 +150,9 @@ target filename, such as when you copy from a bare filecap. (#761)
"tahoe deep-check --repair" should tolerate repair failures now, instead of
halting traversal. (#874, #786)
"tahoe create-alias" no longer corrupts the aliases file if it had
previously been edited to have no trailing newline. (#741)
Many small packaging improvements were made to facilitate the "tahoe-lafs"
package being included in Ubuntu. Several mac/win32 binary libraries were
removed, some figleaf code-coverage files were removed, a bundled copy of
@ -155,6 +160,17 @@ darcsver-1.2.1 was removed, and additional licensing text was added.
Several DeprecationWarnings for python2.6 were silenced. (#859)
The checker --add-lease option would sometimes fail for shares stored
on old (Tahoe v1.2.0) servers. (#875)
The documentation for installing on Windows (docs/install.html) has been
improved. (#773)
For other changes not mentioned here, see
<http://allmydata.org/trac/tahoe/query?milestone=1.6.0&keywords=!~news-done>.
To include the tickets mentioned above, go to
<http://allmydata.org/trac/tahoe/query?milestone=1.6.0>.
* Release 1.5.0 (2009-08-01)