faq answer on epmfs

README.md

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

man/mergerfs.1

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