Merge pull request #402 from tuesdayinsighter/patch-1

Fix multiple typos in Efficiency_of_sealing.md

docs/operation/Efficiency_of_sealing.md

@@ -71,7 +71,7 @@ There are many factors cobtributes to the performance of your sealing pipeline.
 
 ### Sealing storage
 
-During sealing of a sector, cahce files will be generated by the proof algorithm which requires high disk IO speed. Low IO speed may result in idling of your computation resources (CPUs/GPUs). 
+During sealing of a sector, cache files will be generated by the proof algorithm which requires high disk IO speed. Low IO speed may result in idling of your computation resources (CPUs/GPUs). 
 
 Choose apropriate hardware using forumla below.
 
@@ -108,11 +108,11 @@ Assemble a pre-existing array.
 
 More on `mdadm`, please visit [here](http://raid.wiki.kernel.org/). Get latest version from [here](http://www.kernel.org/pub/linux/utils/raid/mdadm/).
 
-### Permenant storage
+### Permanent storage
 
-Possible adversaries to overcome when setting up permenant storage.   
+Possible adversaries to overcome when setting up permanent storage.   
 
-1. When a sector is sealed, it will be transferred from sealer to permenant storage which takes up network bandwidth and disk IOs.
+1. When a sector is sealed, it will be transferred from sealer to permanent storage which takes up network bandwidth and disk IOs.
 2. During a `windowPost`, random selections files will be read in large number. Slow read may result in failed `windowPost`.
 3. Choose high RAID level to have redunancy when possible. Eg, RAID5, RAID6, RAID10.
 4. Monitor usage of your disk array. 
@@ -179,7 +179,7 @@ Set following environment variable to speed up P1.
 ```bash
 # Store cache files in RAM; for 32G sectors, it will cost 56G RAM
 export FIL_PROOFS_MAXIMIZE_CACHING=1  
-# Use mutiple cores for P1
+# Use multiple cores for P1
 export FIL_PROOFS_USE_MULTICORE_SDR=1
 ```
 
@@ -273,7 +273,7 @@ From the table above, we know that daily growth will be bottlenecked by P1. Adju
 | P2     | 30      | 1        | 2 = 1 / (30 /60)     | 1536 G | 96 G = 1*96        |
 | Commit | 35      | 1        | 1.71 = 1 / (35 /60)  | 1316 G | 192 G = 1*128+64   |
 
-The goal is to have `output` for each task to be as close as possilbe so that the sealing pipeline runs in its maximum efficiency. Things to watchout for includes...
+The goal is to have `output` for each task to be as close as possible so that the sealing pipeline runs in its maximum efficiency. Things to watchout for includes...
 
 1. `hourly production` for Commit is lower than P1, which may result in tasks backlogged in Commit phase.
 2. When one type of tasks being overly efficient than others, resources may become idle.