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
2.8 KiB

  1. # Usage and Functionality
  2. ## Can mergerfs be used with filesystems which already have data?
  3. Yes. mergerfs is really just a proxy and does **NOT** interfere with
  4. the normal form or function of the filesystems, mounts, or paths it
  5. manages. It literally is interacting with your filesystems as any
  6. other application does. It can not do anything that any other random
  7. piece of software can't do.
  8. mergerfs is **not** a traditional filesystem that takes control over
  9. the underlying disk or block device. mergerfs is **not** RAID. It does
  10. **not** manipulate the data that passes through it. It does **not**
  11. shard data across filesystems. It only shards some **behavior** and
  12. aggregates others.
  13. ## Can filesystems be removed from the pool without affecting them?
  14. Yes. See previous question's answer.
  15. ## Can mergerfs be removed without affecting the data?
  16. Yes. See the previous question's answer.
  17. ## Can filesystems be moved to another pool?
  18. Yes. See the previous question's answer.
  19. ## Can filesystems be part of multiple pools?
  20. Yes.
  21. ## How do I migrate data into or out of the pool when adding/removing filesystems?
  22. There is no need to do so. See the previous questions.
  23. ## How do I remove a filesystem but keep the data in the pool?
  24. Nothing special needs to be done. Remove the branch from mergerfs'
  25. config and copy (rsync) the data from the removed filesystem into the
  26. pool. The same as if it were you transfering data from one filesystem
  27. to another.
  28. If you wish to continue using the pool with all data available while
  29. performing the transfer simply create a temporary pool without the
  30. branch in question and then copy the data from the branch to the
  31. temporary pool. It would probably be a good idea to set the branch
  32. mode to `RO` prior to doing this to ensure no new content is written
  33. to the filesystem while performing the copy. However, it is typically
  34. good practice to run rsync or rclone again after the first copy
  35. finishes to ensure nothing is left behind.
  36. NOTE: Above recommends to "copy" rather than "move" because you want
  37. to ensure that your data is transfered before wiping the drive or
  38. filesystem.
  39. ## Can filesystems still be used directly? Outside of mergerfs while pooled?
  40. Yes, out-of-band interaction is generally fine. Remember that mergerfs
  41. is just a userland application like any other software so its
  42. interactions with the underlying filesystems is no different. It would
  43. be like two normal applications interacting with the
  44. filesystem. However, it's not recommended to write to the same file
  45. from within the pool and from without at the same time. Especially if
  46. using page caching (`cache.files!=off`) or writeback caching
  47. (`cache.writeback=true`). That said this risk is really not
  48. really different from the risk of two applications writing to
  49. the same file under normal conditions.