faq answer on epmfs

This commit is contained in:
Antonio SJ Musumeci 2017-11-07 14:48:38 -05:00
parent a8e6128034
commit 7207e7fdd6
2 changed files with 27 additions and 2 deletions

View File

@ -297,7 +297,7 @@ There is a pseudo file available at the mount point which allows for the runtime
Even if xattrs are disabled for mergerfs the [{list,get,set}xattrs](http://linux.die.net/man/2/listxattr) calls against this pseudo file will still work.
Any changes made at runtime are **not** persisted. If you wish for values to persist they must be included as options wherever you configure the mounting of mergerfs (fstab).
Any changes made at runtime are **not** persisted. If you wish for values to persist they must be included as options wherever you configure the mounting of mergerfs (/etc/fstab).
##### Keys #####
@ -316,6 +316,8 @@ Used to query or modify the list of source mounts. When modifying there are seve
| -< | remove first in list |
| -> | remove last in list |
`xattr -w user.mergerfs.srcmounts +</mnt/drive3 /mnt/pool/.mergerfs`
###### minfreespace ######
Input: interger with an optional multiplier suffix. **K**, **M**, or **G**.
@ -609,6 +611,12 @@ Whenever you run into a split permission issue (seeing some but not all files) t
If using a network filesystem such as NFS, SMB, CIFS (Samba) be sure to pay close attention to anything regarding permissioning and users. Root squashing and user translation for instance has bitten a few mergerfs users. Some of these also affect the use of mergerfs from container platforms such as Docker.
#### Why is only one drive being used?
Are you using a path preserving policy? The default policy for file creation is `epmfs`. That means only the drives with the path preexisting will be considered when creating a file. If you don't care about where files and directories are created you likely shouldn't be using a path preserving policy and instead something like `mfs`.
This can be especially apparent when filling an empty pool from an external source. If you do want path preservation you'll need to perform the manual act of creating paths on the drives you want the data to land on before transfering your data.
#### Why use mergerfs over mhddfs?
mhddfs is no longer maintained and has some known stability and security issues (see below). MergerFS provides a superset of mhddfs' features and should offer the same or maybe better performance.

View File

@ -714,7 +714,7 @@ against this pseudo file will still work.
.PP
Any changes made at runtime are \f[B]not\f[] persisted.
If you wish for values to persist they must be included as options
wherever you configure the mounting of mergerfs (fstab).
wherever you configure the mounting of mergerfs (/etc/fstab).
.SS Keys
.PP
Use \f[C]xattr\ \-l\ /mount/point/.mergerfs\f[] to see all supported
@ -766,6 +766,8 @@ T}@T{
remove last in list
T}
.TE
.PP
\f[C]xattr\ \-w\ user.mergerfs.srcmounts\ +</mnt/drive3\ /mnt/pool/.mergerfs\f[]
.SS minfreespace
.PP
Input: interger with an optional multiplier suffix.
@ -1313,6 +1315,21 @@ Root squashing and user translation for instance has bitten a few
mergerfs users.
Some of these also affect the use of mergerfs from container platforms
such as Docker.
.SS Why is only one drive being used?
.PP
Are you using a path preserving policy?
The default policy for file creation is \f[C]epmfs\f[].
That means only the drives with the path preexisting will be considered
when creating a file.
If you don\[aq]t care about where files and directories are created you
likely shouldn\[aq]t be using a path preserving policy and instead
something like \f[C]mfs\f[].
.PP
This can be especially apparent when filling an empty pool from an
external source.
If you do want path preservation you\[aq]ll need to perform the manual
act of creating paths on the drives you want the data to land on before
transfering your data.
.SS Why use mergerfs over mhddfs?
.PP
mhddfs is no longer maintained and has some known stability and security