You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

75 lines
3.5 KiB

  1. # Configuration and Policies
  2. ## What policies should I use?
  3. Unless you're doing something more niche the average user is probably
  4. best off using `mfs` for `category.create`. It will spread files out
  5. across your branches based on available space. Use `mspmfs` if you
  6. want to try to colocate the data a bit more. You may want to use `lus`
  7. if you prefer a slightly different distribution of data if you have a
  8. mix of smaller and larger filesystems. Generally though `mfs`, `lus`,
  9. or even `rand` are good for the general use case. If you are starting
  10. with an imbalanced pool you can use the tool **mergerfs.balance** to
  11. redistribute files across the pool.
  12. If you really wish to try to colocate files based on directory you can
  13. set `func.create` to `epmfs` or similar and `func.mkdir` to `rand` or
  14. `eprand` depending on if you just want to colocate generally or on
  15. specific branches. Either way the _need_ to colocate is rare. For
  16. instance: if you wish to remove the device regularly and want the data
  17. to predictably be on that device or if you don't use backup at all and
  18. don't wish to replace that data piecemeal. In which case using path
  19. preservation can help but will require some manual
  20. attention. Colocating after the fact can be accomplished using the
  21. **mergerfs.consolidate** tool. If you don't need strict colocation
  22. which the `ep` policies provide then you can use the `msp` based
  23. policies which will walk back the path till finding a branch that
  24. works.
  25. Ultimately there is no correct answer. It is a preference or based on
  26. some particular need. mergerfs is very easy to test and experiment
  27. with. I suggest creating a test setup and experimenting to get a sense
  28. of what you want.
  29. `epmfs` is the default `category.create` policy because `ep` policies
  30. are not going to change the general layout of the branches. It won't
  31. place files/dirs on branches that don't already have the relative
  32. branch. So it keeps the system in a known state. It's much easier to
  33. stop using `epmfs` or redistribute files around the filesystem than it
  34. is to consolidate them back.
  35. ## What settings should I use?
  36. Depends on what features you want. Generally speaking, there are no
  37. "wrong" settings. All settings are feature related. The best bet is to
  38. read over the available options and choose what fits your
  39. situation. If something isn't clear from the documentation please
  40. reach out and the documentation will be improved.
  41. For the average person the settings described in the [Quick
  42. Start](../quickstart.md) are sufficient.
  43. ## Why are all my files ending up on 1 filesystem?!
  44. Did you start with empty filesystems? Did you explicitly configure a
  45. `category.create` policy? Are you using an `existing path` / `path
  46. preserving` policy?
  47. The default create policy is `epmfs`. That is a path preserving
  48. algorithm. With such a policy for `mkdir` and `create` with a set of
  49. empty filesystems it will select only 1 filesystem when the first
  50. directory is created. Anything, files or directories, created in that
  51. first directory will be placed on the same branch because it is
  52. preserving paths.
  53. This may catch new users off guard but this policy is the safest
  54. policy to start with as it will not change the general layout of the
  55. underlying filesystems. If you do not care about path preservation
  56. (most shouldn't) and wish your files to be spread across all your
  57. filesystems change to `mfs` or similar
  58. [policy](../config/functions_categories_and_policies.md). If you do
  59. want path preservation you'll need to perform the manual act of
  60. creating paths on the filesystems you want the data to land on before
  61. transferring your data.