If you use a policy that excludes placement based on existence of directory you WILL have situations where a link is not possible. This should be laid out fully in the docs. This is fundamental to the user's ask of not to place files in places where there is no path. You must keep in mind order of operations and functions. If a directory is on "epmfs" and the source of your link request is not on that branch... tough. It can't link it. That's why the docs in the colocation section suggest 1) don't bother. most people have no need for colocation. and then 2) use a different policy for mkdir than create.
Posts by trapexit
-
-
just wanted to be sure because mergerfs will choose which drive to put each file on to balance the pool ( currently set to "most free space". I wasn't sure if it mattered if it tries to copy multiple files to the same drive at once if it would matter in any way.
It matters in so much as naturally the device has limit performance. If you use mfs and have a singular branch that ends up being the target each create naturally it will be slower than if you had random or pfrd and spread the load over multiple branches. But that's not a mergerfs issue but a matter of fact given the configuration you selected.
-
For mmap to be supported with mergerfs it must be enabled in current releases. Many users of sqlite3 force it to work with mmap despite not needing to and do a poor job of handling the errors. "No such device" is the low level error. You can read more in the mergerfs docs.
-
> It likes to leave empty directories behind when deleted.
Yes, it leaves the directory till it is actually deleted. mergerfs has no way to know that a directory is empty and you think it shouldn't exist or not. It isn't marking files/dirs whether or not it happened to be the one that created it or you did out of band. And some policies would not work properly if it did.
As for the OP. The tool is nothing more than a wrapper on rsync and shows you exactly what is being called. If rsync can't remove the file then you aren't running it as root or otherwise have a strange setup. As I point out in the docs though there is really little technical reasons to "balance" the pool. https://trapexit.github.io/mer…nce-files-across-the-pool
-
Off hand not sure why that would be. If you have time could you strace tftp server when using wit with mergerfs? Or show details of your setup (tftp server in particular) and a simple way to test if possible and I can look into it.
-
Your data isn't lost. There is nothing to recover.
Storage doesn't just erase itself. mergerfs was specifically created to not interfere with traditional filesystems. I would recommend strongly that you learn more about a technology before you use it because if you are worried about losing your data then you will eventually need to restore and recover it. Waiting till after the inevitable failure is not a good idea.
Regardless, you simply need to recreate the mergerfs pool. You said you reinstalled so naturally you blew away all the config.
-
-
-
Define "didn't work."
mergerfs doesn't manipulate the filesystems in the pool in any special way.
Usage and Functionality - mergerfs
You mount the filesystems, create the mergerfs pool, the files will be there. It's trivial to check. Open a terminal, check the list of mounts, confirm mergerfs is running, goto the mountpoint, run `ls` or similar. If as a non-root identity you don't see things but as root you do it's because your permissions are messed up.
-
> This should prevent OMV to spin up all drives but only the drive I'm working with a directory.
Limit Drive Spinupa featureful union filesystem. Contribute to trapexit/mergerfs development by creating an account on GitHub.github.comtl;dr You really can't do that.
-
mergerfs has an inode calculation option that can be used to do whatever you like wrt calculation. If there isn't a behavior there that works that file a ticket and I can look into it.
GitHub - trapexit/mergerfs: a featureful union filesystema featureful union filesystem. Contribute to trapexit/mergerfs development by creating an account on GitHub.github.com -
mergerfs will show what is available to it. You should confirm your setup. If the 14TB drive's filesystem is in the pool and you have proper perms then it should show.
-
I already changed the policy to most free space for the mergerfs pool after reading exact the github link you posted ;-).
Thanks for your suggestion, I'll go with this policy.
I can't understand why "most free space" isn't the default policy.
As explained in the docs:
GitHub - trapexit/mergerfs: a featureful union filesystema featureful union filesystem. Contribute to trapexit/mergerfs development by creating an account on GitHub.github.comQuoteThe default create policy is
epmfs. That is a path preserving algorithm. With such a policy formkdirandcreatewith 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.This catches a lot of new users off guard but changing the default would break the setup for many existing users and this policy is the safest policy as it will not change the general layout of the existing filesystems. If you do not care about path preservation and wish your files to be spread across all your filesystems change to
mfsor similar policy as described above. 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. Settingfunc.mkdir=epallcan simplify managing path preservation forcreate. Or usefunc.mkdir=randif you're interested in just grouping together directory content by filesystem.It is easier to keep entropy low by default and increase it afterwards than have increased entropy be the default and trying to clean up after you realize you don't want that.
-
Just use `ff`... first found and put them in the order you want. And set minfreespace accordingly.
-
I'm not sure what you're asking exactly. If you don't want mergerfs to consider path existence into account when create, link, or rename you need to set it to a policy that doesn't do so. You could also set ignorepponrename but that kinda defeats the purpose of using a policy that uses that detail.
GitHub - trapexit/mergerfs: a featureful union filesystema featureful union filesystem. Contribute to trapexit/mergerfs development by creating an account on GitHub.github.com -
You *could* use mergerfs for the config and such by enabling page caching but it is generally not recommended. As I point out in the docs certain workloads, like databases, are negatively impacted by the increased latency that mergerfs introduces due to the FUSE technology it leverages. If/when the Linux kernel allows "passthrough" of file IO that limitation should be removed.
-
With 1 parity filesystem you only have 1 filesystem loss resiliency.
So if you delete files from multiple filesystems you are introducing multiple filesystem losses.
-
What version of mergerfs? Are you exporting it via NFS? Have you updated to the latest version?
GitHub - trapexit/mergerfs: a featureful union filesystema featureful union filesystem. Contribute to trapexit/mergerfs development by creating an account on GitHub.github.com -
It's the plugin, not mergerfs. mergerfs doesn't know the config in OMV changed. It has to be told. Since OMV plugin just updates some config somewhere and doesn't modify the runtime there isn't anything mergerfs can do.
-
https://github.com/trapexit/mergerfs-tools#mergerfsbalance has descriptions for the arguments as does running it with --help.
