Merge pull request #1412 from trapexit/docs

Rework questions on what settings and policies to use
2 days ago · 371764d800
1 changed files with 80 additions and 55 deletions
--- a/mkdocs/docs/faq/configuration_and_policies.md
+++ b/mkdocs/docs/faq/configuration_and_policies.md
@ -1,60 +1,85 @@
 # Configuration and Policies
 ## What policies should I use?
 Unless you're doing something more niche the average user is probably
 best off using `mfs` for `category.create`. It will spread files out
 across your branches based on available space. Use `mspmfs` if you
 want to try to colocate the data a bit more. You may want to use `lus`
 if you prefer a slightly different distribution of data if you have a
 mix of smaller and larger filesystems. Generally though `mfs`, `lus`,
 or even `rand` are good for the general use case. If you are starting
 with an imbalanced pool you can use the tool **mergerfs.balance** to
 redistribute files across the pool. That said "balancing" really
 should not be needed. There is really no inherent issue with being
 unbalanced. "Optimal" layout is related to usage patterns and most
 people don't have patterns that are performance sensitive or specific
 enough to do anything about. Additionally, the balance tool is very
 simplistic and was not written to be as serious tool that accounts for
 edge cases.
 If you really wish to try to colocate files based on directory you can
 set `func.create` to `epmfs` or similar and `func.mkdir` to `rand` or
 `eprand` depending on if you just want to colocate generally or on
 specific branches. Either way the _need_ to colocate is rare. For
 instance: if you wish to remove the device regularly and want the data
 to predictably be on that device or if you don't use backup at all and
 don't wish to replace that data piecemeal. In which case using path
 preservation can help but will require some manual
 attention. Colocating after the fact can be accomplished using the
 **mergerfs.consolidate** tool. If you don't need strict colocation
 which the `ep` policies provide then you can use the `msp` based
 policies which will walk back the path till finding a branch that
 works.
 Ultimately there is no correct answer. It is a preference or based on
 some particular need. mergerfs is very easy to test and experiment
 with. I suggest creating a test setup and experimenting to get a sense
 of what you want.
 `epmfs` is the default `category.create` policy because `ep` policies
 are not going to change the general layout of the branches. It won't
 place files/dirs on branches that don't already have the relative
 branch. So it keeps the system in a known state. It's much easier to
 stop using `epmfs` or redistribute files around the filesystem than it
 is to consolidate them back.
 ## What settings should I use?
 Depends on what features you want. Generally, there are no "good",
 "bad", "inefficient", or "optimal" settings. Options are almost
 exclusively functional. Meaning they change the behavior of the
 software. It is best to read over the available options and choose
 what fits your use case. If something is not clear from the
 documentation please reach out and the documentation will be improved.
 ## What settings should I use?
 The settings described in the [Quick Start](../quickstart.md) are
 sufficient for most users.
 Filesystems are complex and use cases numerous. There simply is no way
 to provide a singular setup that works for all situations. Since
 mergerfs [does not impact](usage_and_functionality.md) the underlying
 filesystems and can be added or removed without any impact it is
 extremely easy to test and experiment with different settings.
 ## How can I ensure files are collocated on the same branch?
 Many people like the idea of ensuring related files, such as all the
 files to a TV show season or songs in an album, are stored on the same
 storage device. However, most people have no actual need for this
 behavior.
 1. If you backup your data it is extremely likely your backup solution
   can restore only those files you are missing.
 2. Software such as **Sonarr** can manage the downloading and post
   processing of bespoke episodes which may be missing in a
   season. Either by downloading the episode individually if available
   or by downloading a full season.
 3. There is no benefit to keeping files collocated with regard to
   drive spinup, caching, or other secondary concern.
 The main use case for wanting collocation is where the branch is going
 to be removed from the pool and you wish to have all data from some
 logical set on that device. Such as you intend to take a drive out of
 the pool to take on a trip and want a whole show on the
 drive. However, even in these situations you typically end up needing
 to curate the files anyway because it has show A but not show B.
 All that said you can accomplish collocation to varying degrees using
 the following methods:
 1. Use
   [mergerfs.consolidate](https://github.com/trapexit/mergerfs-tools/blob/master/src/mergerfs.consolidate)
   when consolidation is needed.
 2. Use a `msp` create policy.
 3. Use `epmfs` or other `ep` create policy and manually create paths
   on the branches directly.
 4. Use a `ep` `create` policy and `rand` for `mkdir`.
 ## How can I balance files across the pool?
 Similar to collocation there is generally little reason to balance
 files.
 1. Since prediction of a filesystem's death or loss of data is near
   impossible there is little reason to balance in hopes of limiting
   data loss.
 2. While performance could be impacted by having too much reading or
   writing happen to singular underlying filesystems balancing won't
   help unless you have the ability to manage the access patterns to
   the pool.
 3. Over time most configurations will lead to a random distribution of
   files across the branches which is effectively "balancing."
 If you wish to move files around or balance the pool you can:
 Depends on what features you want. Generally speaking, there are no
 "wrong" settings. All settings are feature related. The best bet is to
 read over the available options and choose what fits your
 situation. If something isn't clear from the documentation please
 reach out and the documentation will be improved.
 1. Use `rand` or `pfrd` create policies and just use your system as
   normal.
 2. Write simple scripts using rsync or similar to move files around as
   you wish.
 3. Use
   [mergerfs.balance](https://github.com/trapexit/mergerfs-tools/blob/master/src/mergerfs.balance). Keep
   in mind that this tool is really just an example of how to
   accomplish such a task.
 For the average person the settings described in the [Quick
 Start](../quickstart.md) are sufficient.
 ## Why are all my files ending up on 1 filesystem?!
@ -67,15 +92,15 @@ The default create policy is `epmfs`. That is a path preserving
 algorithm. With such a policy for `mkdir` and `create` with a set of
 empty filesystems it will select only 1 filesystem when the first
 directory is created. Anything, files or directories, created in that
 first directory will be placed on the same branch because it is
 preserving paths.
 directory will be placed on the same branch because it is preserving
 paths.
 This may catch new users off guard but this policy is the safest
 policy to start with as it will not change the general layout of the
 underlying filesystems. If you do not care about path preservation
 (most shouldn't) and wish your files to be spread across all your
 filesystems change to `mfs` or similar
 filesystems change to `rand`, `pfrd`, `mfs` or similar
 [policy](../config/functions_categories_and_policies.md). If you do
 want path preservation you'll need to perform the manual act of
 creating paths on the filesystems you want the data to land on before
 transferring your data.
 writing said data.