You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by dl...@apache.org on 2014/04/16 01:21:16 UTC

svn commit: r1587749 - /accumulo/site/trunk/content/release_notes/1.6.0.mdtext

Author: dlmarion
Date: Tue Apr 15 23:21:15 2014
New Revision: 1587749

URL: http://svn.apache.org/r1587749
Log:
Changed name of ACCUMULO-118 feature

Modified:
    accumulo/site/trunk/content/release_notes/1.6.0.mdtext

Modified: accumulo/site/trunk/content/release_notes/1.6.0.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/trunk/content/release_notes/1.6.0.mdtext?rev=1587749&r1=1587748&r2=1587749&view=diff
==============================================================================
--- accumulo/site/trunk/content/release_notes/1.6.0.mdtext (original)
+++ accumulo/site/trunk/content/release_notes/1.6.0.mdtext Tue Apr 15 23:21:15 2014
@@ -24,7 +24,7 @@ Accumulo 1.6.0 runs on Hadoop 1, however
 
 ## Notable Improvements
 
-### Multiple namenode support
+### Multiple volume support
 
 [BigTable's][1] design allows for its internal metadata to automatically spread across multiple nodes.  Accumulo has followed this design and scales very well as a result.  There is one impediment to scaling though, and this is the HDFS namenode.  There are two problems with the namenode when it comes to scaling.  First, the namenode stores all of its filesystem metadata in memory on a single machine.  This introduces an upper bound on the number of files Accumulo can have.  Second, there is an upper bound on the number of file operations per second that a single namenode can support.  For example, a namenode can only support a few thousand delete or create file request per second.