Generated.

[homepage.git] / blog / index.html

diff --git a/blog/index.html b/blog/index.html
index 93ac26e8a6b03358422819a5598582cc3849de37..7cee2eb902ecf9cfa042564833bbdb2c0914c79d 100644 (file)
--- a/blog/index.html
+++ b/blog/index.html
@@ -55,7 +55,7 @@ Hughes</li>
 
 <li>USENIX FAST'08
 <a href="https://www.usenix.org/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/">An
-cAnalysis of Data Corruption in the Storage Stack</a> -
+cAnalysis of Data Corruption in the Storage Stack</a> by
 L. N. Bairavasundaram, G. R. Goodson, B. Schroeder, A. C.
 Arpaci-Dusseau, and R. H. Arpaci-Dusseau</li>
 
@@ -72,7 +72,7 @@ Jiang, Chongfeng Hu, Yuanyuan Zhou, and Arkady Kanevsky</li>
 
 <li>SIGMETRICS 2007
 <a href="http://research.cs.wisc.edu/adsl/Publications/latent-sigmetrics07.pdf">An
-analysis of latent sector errors in disk drives</a> -
+analysis of latent sector errors in disk drives</a> by
 L. N. Bairavasundaram, G. R. Goodson, S. Pasupathy, and J. Schindler</li>
 
 </ul>
@@ -84,7 +84,10 @@ redundant storage systems.  Details matter.  And unfortunately there
 are few options on Linux addressing all the identified issues.  Both
 ZFS and Btrfs are doing a fairly good job, but have legal and
 practical issues on their own.  I wonder how cluster file systems like
-Ceph do in this regard.</p>
+Ceph do in this regard.  After, all the old saying, you know you have
+a distributed system when the crash of a compyter you have never heard
+of stops you from getting any work done.  The same holds true if fault
+tolerance do not work.</p>
 
 <p>Just remember, in the end, it do not matter how redundant, or how
 fault tolerant your storage is, if you do not continuously monitor its