github-mirror/mergerfs
github-mirror/mergerfs
2
0
Fork 0
mirror of https://github.com/trapexit/mergerfs.git synced 2025-04-24 22:14:05 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Rework questions on what settings and policies to use

Browse Source
This commit is contained in:
Antonio SJ Musumeci 2025-02-11 19:44:52 -06:00
parent aa97bac533
commit 1c44ef7967
1 changed files with 81 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
mkdocs/docs/faq/configuration_and_policies.md
View File

@ -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 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.
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.
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:
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.