Another update.

[homepage.git] / blog / data / 2017-11-01-storage-fault-tolerance.txt

diff --git a/blog/data/2017-11-01-storage-fault-tolerance.txt b/blog/data/2017-11-01-storage-fault-tolerance.txt
index df451fc356d52634dd797fd518e67f0c75460b6f..c03fe7c63eed4faec6a3cd2098f1171b6f9dd967 100644 (file)
--- a/blog/data/2017-11-01-storage-fault-tolerance.txt
+++ b/blog/data/2017-11-01-storage-fault-tolerance.txt
@@ -65,10 +65,14 @@ 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, there is an old saying, you know
-you have a distributed system when the crash of a compyter you have
+you have a distributed system when the crash of a computer 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
 status to detect and replace failed disks.</p>
+
+<p>As usual, if you use Bitcoin and want to show your support of my
+activities, please send Bitcoin donations to my address
+<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>