svn commit: r923267 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.5.2.html

[bu...@apache.org]

Author: buildbot
Date: Tue Sep 23 16:53:37 2014
New Revision: 923267

Log:
Staging update by buildbot for accumulo

Modified:
    websites/staging/accumulo/trunk/content/   (props changed)
    websites/staging/accumulo/trunk/content/release_notes/1.5.2.html

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Sep 23 16:53:37 2014
@@ -1 +1 @@
-1627088
+1627089

Modified: websites/staging/accumulo/trunk/content/release_notes/1.5.2.html
==============================================================================
--- websites/staging/accumulo/trunk/content/release_notes/1.5.2.html (original)
+++ websites/staging/accumulo/trunk/content/release_notes/1.5.2.html Tue Sep 23 16:53:37 2014
@@ -227,17 +227,17 @@ HeapIterator in common cases.</p>
 <h3 id="write-ahead-log-sync-implementation">Write-Ahead log sync implementation</h3>
 <p>In Hadoop-2, two implementations of sync are provided: hflush and hsync. Both of these
 methods provide a way to request that the datanodes write the data to the underlying
-medium and not just hold it in memory (the 'fsync' syscall). While both of these methods
-inform the Datanodes to sync the relevant block(s), hflush does not wait for acknowledgement
-from the Datanodes that the sync finished, where hsync does. To provide the most reliable system
-"out of the box", Accumulo defaults to hsync so that your data is as secure as possible in 
+medium and not just hold it in memory (the <em>fsync</em> syscall). While both of these methods
+inform the Datanodes to sync the relevant block(s), <em>hflush</em> does not wait for acknowledgement
+from the Datanodes that the sync finished, where <em>hsync</em> does. To provide the most reliable system
+"out of the box", Accumulo defaults to <em>hsync</em> so that your data is as secure as possible in 
 a variety of situations (notably, unexpected power outages).</p>
 <p>The downside is that performance tends to suffer because waiting for a sync to disk is a very
 expensive operation. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2842">ACCUMULO-2842</a> introduces a new system property, tserver.wal.sync.method,
 that lets users to change the HDFS sync implementation from <em>hsync</em> to <em>hflush</em>. Using <em>hflush</em> instead
 of <em>hsync</em> may result in about a 30% increase in ingest performance.</p>
 <p>For users upgrading from Hadoop-1 or Hadoop-0.20 releases, <em>hflush</em> is the equivalent of how
-sync was implemented and should give equivalent performance.</p>
+sync was implemented in these older versions of Hadoop and should give comparable performance.</p>
 <h3 id="server-side-mutation-queue-size">Server-side mutation queue size</h3>
 <p>When users desire writes to be as durable as possible, using <em>hsync</em>, the ingest performance
 of the system can be improved by increasing the tserver.mutation.queue.max property. The cost