Generated.

diff --git a/blog/Some_notes_on_fault_tolerant_storage_systems.html b/blog/Some_notes_on_fault_tolerant_storage_systems.html
index 53d4d01d3bea6c73765189542009ee0ea9109092..636dfbd4a3e24942856181ca8ff5013588418721 100644 (file)
--- a/blog/Some_notes_on_fault_tolerant_storage_systems.html
+++ b/blog/Some_notes_on_fault_tolerant_storage_systems.html
@@ -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
 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
 
 <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 93ac26e8a6b03358422819a5598582cc3849de37..424fbab6125b171447cc279df7d633124f6a4b9a 100644 (file)
--- a/blog/index.html
+++ b/blog/index.html
@@ -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
 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
 
 <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 d2a8c98f0bc135a35c0a4788e5fcb678c683286f..99889b93e247f2abe30ef476f2561ab1682b3f4a 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -73,7 +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
 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
 
 <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 379da3557b188f3b663898e2018f03dcd4387ff5..ccc804bb4babc24abd8aad34b119f32ea5c58503 100644 (file)
--- a/blog/tags/english/english.rss
+++ b/blog/tags/english/english.rss
@@ -73,7 +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
 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
 
 <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 d5601f956f1d87c0d78b9bbd88e0b46f41eb49b4..7bfc00377ae7e1111dd8ce4396af209a00453b48 100644 (file)
--- a/blog/tags/english/index.html
+++ b/blog/tags/english/index.html
@@ -90,7 +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
 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
 
 <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 4a5e6ba950a2dc4a714a4feaa5538ad6bfb5dd1e..4a2189fdaff2a7927a0db36be69f042c33308141 100644 (file)
--- a/blog/tags/raid/index.html
+++ b/blog/tags/raid/index.html
@@ -90,7 +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
 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
 
 <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 0b18fcd92f787dae21524b70e612b8ab7e80eed5..804537e8c7a3b4d42b761839f93a41ae480df083 100644 (file)
--- a/blog/tags/raid/raid.rss
+++ b/blog/tags/raid/raid.rss
@@ -73,7 +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
 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
 
 <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 2b15f0b2a85af8ccc67db1da67b50d70028a40aa..c95ec69c755edfc5526565e981ce8422dc229f82 100644 (file)
--- a/blog/tags/sysadmin/index.html
+++ b/blog/tags/sysadmin/index.html
@@ -90,7 +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
 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
 
 <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 639e64b2bf0194a133aa336cc9c9893f32e6881e..73a97d3871b0d23fbf2061cfe84544ab1a972516 100644 (file)
--- a/blog/tags/sysadmin/sysadmin.rss
+++ b/blog/tags/sysadmin/sysadmin.rss
@@ -73,7 +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
 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
 
 <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