svn commit: r1626809 - /accumulo/site/trunk/content/release_notes/1.5.2.mdtext

[el...@apache.org]

Author: elserj
Date: Mon Sep 22 15:37:22 2014
New Revision: 1626809

URL: http://svn.apache.org/r1626809
Log:
ACCUMULO-3048 Some fixes from Eric

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

Modified: accumulo/site/trunk/content/release_notes/1.5.2.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/trunk/content/release_notes/1.5.2.mdtext?rev=1626809&r1=1626808&r2=1626809&view=diff
==============================================================================
--- accumulo/site/trunk/content/release_notes/1.5.2.mdtext (original)
+++ accumulo/site/trunk/content/release_notes/1.5.2.mdtext Mon Sep 22 15:37:22 2014
@@ -39,7 +39,7 @@ Apache Accumulo 1.5.2 includes a number 
 ### Write-Ahead Log sync performance
 
 The Write-Ahead Log (WAL) files are used to ensure durability of updates made to Accumulo.
-A "sync" is called on the file in HDFS to make sure that the changes to the WAL are persisted
+A sync is called on the file in HDFS to make sure that the changes to the WAL are persisted
 to disk, which allows Accumulo to recover in the case of failure. [ACCUMULO-2766][9] fixed
 an issue where an operation against a WAL would unnecessarily wait for multiple syncs, slowing
 down the ingest on the system.
@@ -62,7 +62,7 @@ HeapIterator in common cases.
 
 ### Write-Ahead log sync implementation
 
-In Hadoop-2, two implementation of "sync" are provider: hflush and hsync. Both of these
+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
@@ -72,15 +72,15 @@ a variety of situations (notably, unexpe
 
 The downside is that performance tends to suffer because waiting for a sync to disk is a very
 expensive operation. [ACCUMULO-2842][12] introduces a new system property, tserver.wal.sync.method,
-that lets users to change the HDFS sync implementation from 'hsync' to 'hflush'. Using 'hflush' instead
-of 'hsync' should result in about a 30% increase in ingest performance.
+that lets users to change the HDFS sync implementation from *hsync* to *hflush*. Using *hflush* instead
+of *hsync* may result in about a 30% increase in ingest performance.
 
-For users upgrading from Hadoop-1 or Hadoop-0.20 releases, "hflush" is the equivalent of how
+For users upgrading from Hadoop-1 or Hadoop-0.20 releases, *hflush* is the equivalent of how
 sync was implemented and should give equivalent performance.
 
 ### Server-side mutation queue size
 
-When users desire writes to be as durable as possible, using 'hsync', the ingest performance
+When users desire writes to be as durable as possible, using *hsync*, the ingest performance
 of the system can be improved by increasing the tserver.mutation.queue.max property. The cost
 of this change is that it will cause TabletServers to use additional memory per writer. In 1.5.1,
 the value of this parameter defaulted to a conservative 256K, which resulted in sub-par ingest