Merge pull request #148 from txkxgit/txkx/docu

Txkx/docu

Author: mhx

README.md

@@ -563,7 +563,7 @@ resulting images are significantly smaller. Still, `mkdwarfs` is about
 **4 times faster** and produces and image that's **12 times smaller** than
 the SquashFS image. The DwarFS image is only 0.6% of the original file size.
 
-So why not use `lzma` instead of `zstd` by default? The reason is that `lzma`
+So, why not use `lzma` instead of `zstd` by default? The reason is that `lzma`
 is about an order of magnitude slower to decompress than `zstd`. If you're
 only accessing data on your compressed filesystem occasionally, this might
 not be a big deal, but if you use it extensively, `zstd` will result in
@@ -733,7 +733,7 @@ Summary
     5.85 ± 0.08 times faster than 'squashfs-zstd'
 ```
 
-So DwarFS is almost six times faster than SquashFS. But what's more,
+So, DwarFS is almost six times faster than SquashFS. But what's more,
 SquashFS also uses significantly more CPU power. However, the numbers
 shown above for DwarFS obviously don't include the time spent in the
 `dwarfs` process, so I repeated the test outside of hyperfine:
@@ -746,7 +746,7 @@ user    0m2.154s
 sys     0m1.846s
 ```
 
-So in total, DwarFS was using 5.7 seconds of CPU time, whereas
+So, in total, DwarFS was using 5.7 seconds of CPU time, whereas
 SquashFS was using 20.2 seconds, almost four times as much. Ignore
 the 'real' time, this is only how long it took me to unmount the
 file system again after mounting it.
@@ -988,7 +988,7 @@ user    0m13.234s
 sys     0m1.382s
 ```
 
-So `dwarfsextract` is almost 4 times faster thanks to using multiple
+So, `dwarfsextract` is almost 4 times faster thanks to using multiple
 worker threads for decompression. It's writing about 300 MiB/s in this
 example.
 
@@ -1118,7 +1118,7 @@ user    714m44.286s
 sys     3m6.751s
 ```
 
-So it's an order of magnitude slower than `mkdwarfs` and uses 14 times
+So, it's an order of magnitude slower than `mkdwarfs` and uses 14 times
 as much CPU resources as `mkdwarfs -l9`. The resulting archive it pretty
 close in size to the default configuration DwarFS image, but it's more
 than 50% bigger than the image produced by `mkdwarfs -l9`.
@@ -1174,7 +1174,7 @@ $ ll perl-install.*
 -rw-r--r-- 1 mhx users 1016981520 Mar  6 21:12 perl-install.wim
 ```
 
-So wimlib is definitely much better than squashfs, in terms of both
+So, wimlib is definitely much better than squashfs, in terms of both
 compression ratio and speed. DwarFS is however about 3 times faster to
 create the file system and the DwarFS file system less than half the size.
 When switching to LZMA compression, the DwarFS file system is more than
@@ -1332,7 +1332,7 @@ user    201m37.816s
 sys     2m15.005s
 ```
 
-So it processed 21 MiB out of 48 GiB in half an hour, using almost
+So, it processed 21 MiB out of 48 GiB in half an hour, using almost
 twice as much CPU resources as DwarFS for the *whole* file system.
 At this point I decided it's likely not worth waiting (presumably)
 another month (!) for `mkcromfs` to finish. I double checked that
@@ -1415,7 +1415,7 @@ user    3m43.324s
 sys     0m4.015s
 ```
 
-So `mkdwarfs` is about 50 times faster than `mkcromfs` and uses 75 times
+So, `mkdwarfs` is about 50 times faster than `mkcromfs` and uses 75 times
 less CPU resources. At the same time, the DwarFS file system is 30% smaller:
 
 ```

doc/mkdwarfs.md

@@ -18,13 +18,13 @@ full contents of `/path/dir` with:
 
     mkdwarfs -i /path/dir -o image.dwarfs
 
-After that, you can mount it with dwarfs(1):
+After that, you can mount it using dwarfs(1):
 
     dwarfs image.dwarfs /path/to/mountpoint
 
 ## OPTIONS
 
-There two mandatory options for specifying the input and output:
+There are two mandatory options for specifying the input and output:
 
 - `-i`, `--input=`*path*|*file*:
   Path to the root directory containing the files from which you want to
@@ -78,9 +78,9 @@ Most other options are concerned with compression tuning:
   to the number of processors available on your system. Use this option if
   you want to limit the resources used by `mkdwarfs` or to optimize build
   speed. This option affects only the compression phase.
-  In the compression phase, the worker threads are used to compress the
+  During the compression phase, the worker threads are used to compress the
   individual filesystem blocks in the background. Ordering, segmenting
-  and block building are, again, single-threaded and run independently.
+  and block building are single-threaded and run independently.
 
 - `--compress-niceness=`*value*:
   Set the niceness of compression worker threads. Defaults to 5. This makes
@@ -112,7 +112,7 @@ Most other options are concerned with compression tuning:
   will completely disable duplicate segment search.
 
 - `-W`, `--window-size=`*value*:
-  Window size of cyclic hash used for segmenting. This is again an exponent
+  Window size of cyclic hash used for segmenting. This is an exponent
   to a base of two. Cyclic hashes are used by `mkdwarfs` for finding
   identical segments across multiple files. This is done on top of duplicate
   file detection. If a reasonable amount of duplicate segments is found,
@@ -399,7 +399,7 @@ a library that allows serialization of structures defined in
 [Thrift IDL](https://github.com/facebook/fbthrift/) into an extremely
 compact representation that can be used in-place without the need for
 deserialization. It is very well suited for persistent, memory-mappable
-data. With Frozen, you essentially only pay for what you use: if fields
+data. With Frozen, you essentially only "pay for what you use": if fields
 are defined in the IDL, but they always hold the same value (or are not
 used at all), not a single bit will be allocated for this field even if
 you have a list of millions of items.
@@ -461,7 +461,7 @@ These options are controlled by the `--pack-metadata` option.
   of two. The entries can be decompressed individually, so no
   extra memory is used when accessing the filesystem (except for
   the symbol table, which is only a few hundred bytes). This is
-  turned on by default. For small filesystems, it's possible that
+  enabled by default. For small filesystems, it's possible that
   the compressed strings plus symbol table are actually larger
   than the uncompressed strings. If this is the case, the strings
   will be stored uncompressed, unless `force` is also specified.
@@ -497,10 +497,10 @@ the corresponding packing option.
      plain   |     6,430,275 |   121.30% |  48.36% |  41.37%
     ---------|---------------|-----------|---------|---------
 
-So the default (`auto`) is roughly 20% smaller than not using any
+So, the default (`auto`) is roughly 20% smaller than not using any
 packing (`none` or `plain`). Enabling `all` packing options doesn't
 reduce the size much more. However, it *does* help if you want to
-further compress the block. So if you're really desperately trying
+further compress the block. So, if you're really desperately trying
 to reduce the image size, enabling `all` packing would be an option
 at the cost of using a lot more memory when using the filesystem.
 
@@ -521,7 +521,7 @@ using `--input-list`.
 
 ## FILTER RULES
 
-The filter rules have been inspired by the `rsync` utility. They
+The filter rules have been inspired by the `rsync` utility. These
 look very similar, but there are differences. These rules are quite
 powerful, yet they're somewhat hard to get used to.