Generated.

[homepage.git] / blog / index.rss

diff --git a/blog/index.rss b/blog/index.rss
index 6f8847277d5db8ada204df62b75c14623109b14d..ec8decc975a01108d6927019d09b63de5d20e992 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -44,7 +44,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> by
+Analysis 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>
 
@@ -73,10 +73,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.  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>
+Ceph do in this regard.  After all, there is an 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