Generated.

diff --git a/blog/Some_notes_on_fault_tolerant_storage_systems.html b/blog/Some_notes_on_fault_tolerant_storage_systems.html
index 36e934abf169fbd9b8daf2e623ff487dc826d466..5d39fa2b2af1ba0cfe96847abfe9e5da3654e18d 100644 (file)
--- a/blog/Some_notes_on_fault_tolerant_storage_systems.html
+++ b/blog/Some_notes_on_fault_tolerant_storage_systems.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> 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>
 
@@ -84,10 +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.  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

diff --git a/blog/index.html b/blog/index.html
index 7cee2eb902ecf9cfa042564833bbdb2c0914c79d..2c5eead6fecee68b7671b6ac73ccc7f34ecc17a0 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> 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>
 
@@ -84,10 +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.  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

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

diff --git a/blog/tags/english/english.rss b/blog/tags/english/english.rss
index 3b7c927594c230bc4e36594506fdc708f3cde49d..a6a5a45601597bdd6dafffc686d369833e69acd7 100644 (file)
--- a/blog/tags/english/english.rss
+++ b/blog/tags/english/english.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

diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html
index 42713416dde587c58932dd011951c73d52d8d415..4a616911039cdd0fd6d3fc68cd4c0eb8e321df9f 100644 (file)
--- a/blog/tags/english/index.html
+++ b/blog/tags/english/index.html
@@ -61,7 +61,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>
 
@@ -90,10 +90,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

diff --git a/blog/tags/raid/index.html b/blog/tags/raid/index.html
index 4e20582cdd25f87caf98daaf97e9675bd8990de2..5fecee26c5bd39c020d5229858451455d2376c6c 100644 (file)
--- a/blog/tags/raid/index.html
+++ b/blog/tags/raid/index.html
@@ -61,7 +61,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>
 
@@ -90,10 +90,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

diff --git a/blog/tags/raid/raid.rss b/blog/tags/raid/raid.rss
index 6e9b628118f7c255fb0863b7ed9eefe8562ade55..74aa6fcac2c9fd87eec37eaa61723030114eff18 100644 (file)
--- a/blog/tags/raid/raid.rss
+++ b/blog/tags/raid/raid.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

diff --git a/blog/tags/sysadmin/index.html b/blog/tags/sysadmin/index.html
index 349a787407337194be4e6526686eb85368b305f7..3c20b200f38bd4f441444e0e1cb2c18c8d9ec37c 100644 (file)
--- a/blog/tags/sysadmin/index.html
+++ b/blog/tags/sysadmin/index.html
@@ -61,7 +61,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>
 
@@ -90,10 +90,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

diff --git a/blog/tags/sysadmin/sysadmin.rss b/blog/tags/sysadmin/sysadmin.rss
index 33f3ec11ed86be591f54a5312686e65ded761ef1..1508371d7cb26ad707aa293ce918f4556e6b8666 100644 (file)
--- a/blog/tags/sysadmin/sysadmin.rss
+++ b/blog/tags/sysadmin/sysadmin.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