From: Petter Reinholdtsen Date: Wed, 1 Nov 2017 14:36:00 +0000 (+0100) Subject: Generated. X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/eb2bfefa8ba4f868fc150d096326f1a2cf74be5e Generated. --- diff --git a/blog/Some_notes_on_fault_tolerant_storage_systems.html b/blog/Some_notes_on_fault_tolerant_storage_systems.html index 53d4d01d3b..636dfbd4a3 100644 --- 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 -Ceph do in this regard.

+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.

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 93ac26e8a6..424fbab612 100644 --- 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 -Ceph do in this regard.

+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.

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 d2a8c98f0b..99889b93e2 100644 --- 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 -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 diff --git a/blog/tags/english/english.rss b/blog/tags/english/english.rss index 379da3557b..ccc804bb4b 100644 --- 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 -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 diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html index d5601f956f..7bfc00377a 100644 --- 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 -Ceph do in this regard.

+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.

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 4a5e6ba950..4a2189fdaf 100644 --- 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 -Ceph do in this regard.

+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.

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 0b18fcd92f..804537e8c7 100644 --- 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 -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 diff --git a/blog/tags/sysadmin/index.html b/blog/tags/sysadmin/index.html index 2b15f0b2a8..c95ec69c75 100644 --- 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 -Ceph do in this regard.

+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.

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 639e64b2bf..73a97d3871 100644 --- 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 -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