prepare for 1.0.4 release

git-svn-id: 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/CHANGES.txt b/CHANGES.txt
index dcae8a0..9666dc0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,6 @@
 Hadoop Change Log
-Release 1.0.4 - Unreleased
+Release 1.0.4 - 2012.10.02
diff --git a/src/docs/releasenotes.html b/src/docs/releasenotes.html
index 6500675..2a47e68 100644
--- a/src/docs/releasenotes.html
+++ b/src/docs/releasenotes.html
@@ -2,7 +2,7 @@
 <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>Hadoop 1.0.3 Release Notes</title>
+<title>Hadoop 1.0.4 Release Notes</title>
 <STYLE type="text/css">
 		H1 {font-family: sans-serif}
 		H2 {font-family: sans-serif; margin-left: 7mm}
@@ -10,11 +10,41 @@
-<h1>Hadoop 1.0.3 Release Notes</h1>
+<h1>Hadoop 1.0.4 Release Notes</h1>
 		These release notes include new developer and user-facing incompatibilities, features, and major improvements. 
 <a name="changes"/>
+<h2>Changes since Hadoop 1.0.3</h2>
+<h3>Jiras with Release Notes (describe major or incompatible changes)</h3>
+<h3>Other Jiras (describe bug fixes and minor changes)</h3>
+<li> <a href="">HADOOP-7154</a>.
+     Minor improvement reported by tlipcon and fixed by tlipcon (scripts)<br>
+     <b>Should set MALLOC_ARENA_MAX in</b><br>
+     <blockquote>New versions of glibc present in RHEL6 include a new arena allocator design. In several clusters we&apos;ve seen this new allocator cause huge amounts of virtual memory to be used, since when multiple threads perform allocations, they each get their own memory arena. On a 64-bit system, these arenas are 64M mappings, and the maximum number of arenas is 8 times the number of cores. We&apos;ve observed a DN process using 14GB of vmem for only 300M of resident set. This causes all kinds of nasty issues fo...</blockquote></li>
+<li> <a href="">HDFS-3652</a>.
+     Blocker bug reported by tlipcon and fixed by tlipcon (name-node)<br>
+     <b>1.x: FSEditLog failure removes the wrong edit stream when storage dirs have same name</b><br>
+     <blockquote>In {{FSEditLog.removeEditsForStorageDir}}, we iterate over the edits streams trying to find the stream corresponding to a given dir. To check equality, we currently use the following condition:<br>{code}<br>      File parentDir = getStorageDirForStream(idx);<br>      if (parentDir.getName().equals(sd.getRoot().getName())) {<br>{code}<br>... which is horribly incorrect. If two or more storage dirs happen to have the same terminal path component (eg /data/1/nn and /data/2/nn) then it will pick the wrong strea...</blockquote></li>
+<li> <a href="">MAPREDUCE-4399</a>.
+     Major bug reported by vicaya and fixed by vicaya (performance, tasktracker)<br>
+     <b>Fix performance regression in shuffle </b><br>
+     <blockquote>There is a significant (up to 3x) performance regression in shuffle (vs 0.20.2) in the Hadoop 1.x series. Most noticeable with high-end switches.</blockquote></li>
 <h2>Changes since Hadoop 1.0.2</h2>
 <h3>Jiras with Release Notes (describe major or incompatible changes)</h3>