From: david-sarah Date: Tue, 2 Feb 2010 06:12:56 +0000 (-0800) Subject: More comprehensive changes and ticket references for NEWS X-Git-Tag: allmydata-tahoe-1.6.1~34 X-Git-Url: https://git.rkrishnan.org/listings/pb2client.py?a=commitdiff_plain;h=210afd3e9ef71cd66becff0840cd941add5fe187;p=tahoe-lafs%2Ftahoe-lafs.git More comprehensive changes and ticket references for NEWS --- diff --git a/NEWS b/NEWS index 92415b4a..0f1415bb 100644 --- a/NEWS +++ b/NEWS @@ -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). - -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 +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 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 +. +To include the tickets mentioned above, go to +. + * Release 1.5.0 (2009-08-01)