trapexit

For anyone who wishes to see exactly what mergerfs is doing here... https://github.com/trapexit/mergerfs/blob/latest-release/src/policy_epff.cpp#L108 You don't need to be a developer to understand this is extremely trivial. @Rysz Glad it is useful. And thank you for building and maintaining this plugin.

mergerfs does not care about the underlying filesystem type. All policies work exactly as described in the docs in relation to selection algorithm, filtering, response to readonly, etc. If `/boot` is first and doesn't get filtered out for whatever reason as described in the docs... it would be selected by `ff`.

It does. How are you testing what is opened? As I say in my support docs... I need you to explain very very explicitly what you are doing for me to help. The ff policy is extremely simple and been around for a decade. It works.

Sorry, I thought the question was "use" as in mechanically... safe to use together. Not legally. Yes. mergerfs is ISC licensed. Do whatever you wish within the license requirements. All that I ask is that if you are building tooling / services on top of mergerfs that you tell me about it so I can include it in the docs. https://trapexit.github.io/mergerfs/related_projects/

I'm not a user of UnRAID or all that familiar with the setup being discussed so I really can't speak to what is appropriate or not.

Sorry but I'm not sure what you are asking. It would be more helpful if you could explain what is unclear in the documentation. https://trapexit.github.io/mergerfs/usage_patterns/#tiered-cache

No problem. What you show is `category.create=ff` which means on *create* it will choose the first branch found. You asked about overlapping existing files. That is controlled by the `open` and other function policies. The category wide setting being `category.search=ff`.

Policies decide how a file is selected. You asked how mergerfs selects a file, the "priority". Policies. The first found policy picks the first found. rand chooses random. Etc.

That is all decided by the different policies and such: https://trapexit.github.io/mergerfs/config/functions_categories_and_policies/

My scripts linked to in the docs will move files by time or by percentage full. It sounds to me you should use the latter.

I'm not aware of any software that does that generically. You have to script something yourself. I have some simple shell scripts that do size and time based movement linked from the mergerfs docs. I've been meaning to write something more involved but just haven't gotten around to it. You could look at https://gist.github.com/trapexit/14ef971951b6c1096a7acec203754faa as a template. Move files instead of remove them. I have mine run ever hour.

What's the reason for the cache here? If you have files constantly being written to the cache then you will simply be constantly emptying the cache. Or at least, assuming you can empty the ssd faster than what is written, will do it in regular batches. I use mergerfs to store camera recordings and for the above reason I just let it do its thing directly. A cache is really only useful for bursty loads. I do have a simple app I wrote to clear out old files but that is not mergerfs specific.

Just download the package and install them wherever. https://github.com/trapexit/mergerfs/releases/download/2.36.0/mergerfs-static-linux_amd64.tar.gz It's just a standard tarball with statically compiled binaries. I build them every release.

Because you aren't pulling the latest version of the build image. Docker doesn't just pull updates on demand. It pulls if not already cached or when explicitly told. docker pull trapexit/mergerfs-static-build

1) 2.37.0 isn't released yet so technically you're on your own. 2) I provide static builds now so you could just use those 3) I updated the build image yesterday just for this reason. You have to pull the new version of the image if you want it to work. Apparently MUSL 4 years ago didn't support features I'm using. https://github.com/trapexit/mergerfs/issues/1246