Document nilsimsa and script file order choices

This commit is contained in:
Marcus Holland-Moritz 2020-12-07 22:28:24 +01:00
parent e3bbeac5d6
commit 5c56943a84

View File

@ -119,14 +119,18 @@ Most other options are concerned with compression tuning:
reduce the size of the file system. You can pass either a unix time stamp reduce the size of the file system. You can pass either a unix time stamp
or `now`. or `now`.
* `--order=none`|`path`|`similarity`: * `--order=none`|`path`|`similarity`|`nilsimsa`|`script`:
The order in which files will be written to the filesystem. Currently, The order in which files will be written to the filesystem. Choosing `none`,
the choices are `none`, `path` and `similarity`. With `none`, the files the files will be stored in the order in which they are discovered. With
will be stored in the order in which they are discovered. With `path`, `path`, they will be sorted asciibetically by path name. With `similarity`,
they will be sorted asciibetically by path name. With `similarity`, they they will be ordered using a simple, yet fast and efficient, similarity
will be ordered using a similarity hash function. This is the default, hash function. This is the default, as it will cause similar files to be
as it will cause similar files to be located close to each other, which located close to each other, which means compression will be better.
means compression will be better. `nilsimsa` ordering uses a different similarity function that is *likely*
even better than `similarity`, but is comparatively slow to compute. It
*can* be very slow, though it shouldn't be for typical inputs. YMMV.
Last but not least, if scripting support is built into `mkdwarfs`, you
can choose `script` to let the script determine the order.
* `--blockhash-window-sizes=`*value*[,*value*]...: * `--blockhash-window-sizes=`*value*[,*value*]...:
Window sizes used for block hashing. These sizes, separated by commas, Window sizes used for block hashing. These sizes, separated by commas,