Error adding Unionfs

That I have missed that there was a tool for mergerfs. That is a very useful feature, then it is room for improvements on the UnionFS-plugin in OMV to include it in the future, that would be really nice so you do not need to go to command line to run the tasks. So to run balance you just type # mergerfs.balance /media and it will balance out everything on the pool that is in the relative path folder "/media"? And rsync package is needed to be installed I see.

Ok, you can spread out the newly written data by using and change to "random" policy instead, that will help a little of course, but it will not move any old data on the drives.

I am no expert on filesystems, but a wild brainstorming idea is to have the mergerfs to read and store all metadata while you write or change any data to the pool? The SSD would have all cache to everything on the pool and when Plex needs to scan, the mergerfs cache would give the answer instead of having Plex to scan the whole pool (If there is no new data on the pool that is). I do not know, this would have been an awesome feature and the scan for Plex would be super fast if there is no new data on the pool, but maybe it is not technically possible. ... With this feature, you can obviously not be working with the drives directly, only via the pool so mergerfs can cache all metadata written.

"MergerFS timeout", how often will mergerfs scan the pool?

I don't understand why that would be better. Just turn off auto scanning. Much easier and less complex. Why put in *another* level of caching (the OS already does) just to keep drives from spinning which is 1) totally in the users control in the first place 2) not that common of a need and 3) severely increases the complexity of the project. If you just have mergerfs ignore what data is actually in the pool and make it nothing more than a metadata cache that has to be forcefully or on a schedule refreshed... why not just not look at the pool? Plex doesn't *have* to scan. And when it does it usually is reading files. Not just scanning the directories. Some software looks at extended attributes. That's a lot of random data of unknown purpose to copy around with the hope that some time in the future an app might ask for the same data. That works fine with the OS does it. It doesn't work fine in this usecase. If you put lvmcache or bcache in front of your drives it wouldn't stop them from spinning up either. It might limit it from time to time but wouldn't guarantee anything.


You are hardly the first person to ask for such a feature but it's simply not practical. I built a prototype years ago... it doesn't work in many cases. mergerfs can't even reliably check if a drive is spun up or not. Drives would literally spin up when querying if they were.

.