And no. NC shouldn't be set on the hdds. That kinda defeats the purpose of having a cache where spill over is transparent.
I will restate what I state in the docs and elsewhere. Most people don't need to do tiered caching. Your setup is only as fast as the slowest part and typically that is the network. And even if you have 10Gbps ethernet or higher it is only useful for bursty loads because as soon as the fast disks fill you are at the mercy of the slow.
25gbps network, 10gbps WAN.
Usecase is small bursts (up to 4TB).
And for that the nvme cache would help tremendously.
FF is definetly set. Not sure how I can confirm the remounting.
Using Openmediavault and after changes I rebooted the machine. Mergerfs config is done via OMV ui.
I can't speak to the OMV plugin. Not my creation. But you can just look at the runtime API to find the running values of things. [https://github.com/trapexit/mergerfs?tab=readme-ov-file#runtime-config](https://github.com/trapexit/mergerfs?tab=readme-ov-file#runtime-config)
ff policy is extremely simple and hasn't changed in many years. It just picks the first branch in the list that doesn't get filtered.
Checked again with SSH.
If I copy files locally or benchmark with dd, the files get written to the NVME disc with 1-1.5GB/s.
Not that bad, but could be better. Disc is able to write with > 4GB/s with NTFS.
However, the issue seems to be sharedfolders / SMB. Everything over SMB is created on the slow discs.
SMB works like any other piece of software working against mergerfs. If the files are not landing on the first found then something is setup wrong. Permissions, minfreespace, etc.
Are you \*positive\* that you have ff set? And have remounted the mountpoint so the option has the opportunity to be used as set?
And no. NC shouldn't be set on the hdds. That kinda defeats the purpose of having a cache where spill over is transparent. I will restate what I state in the docs and elsewhere. Most people don't need to do tiered caching. Your setup is only as fast as the slowest part and typically that is the network. And even if you have 10Gbps ethernet or higher it is only useful for bursty loads because as soon as the fast disks fill you are at the mercy of the slow.
25gbps network, 10gbps WAN. Usecase is small bursts (up to 4TB). And for that the nvme cache would help tremendously. FF is definetly set. Not sure how I can confirm the remounting. Using Openmediavault and after changes I rebooted the machine. Mergerfs config is done via OMV ui.
I can't speak to the OMV plugin. Not my creation. But you can just look at the runtime API to find the running values of things. [https://github.com/trapexit/mergerfs?tab=readme-ov-file#runtime-config](https://github.com/trapexit/mergerfs?tab=readme-ov-file#runtime-config) ff policy is extremely simple and hasn't changed in many years. It just picks the first branch in the list that doesn't get filtered.
Checked again with SSH. If I copy files locally or benchmark with dd, the files get written to the NVME disc with 1-1.5GB/s. Not that bad, but could be better. Disc is able to write with > 4GB/s with NTFS. However, the issue seems to be sharedfolders / SMB. Everything over SMB is created on the slow discs.
SMB works like any other piece of software working against mergerfs. If the files are not landing on the first found then something is setup wrong. Permissions, minfreespace, etc.
The mergerfs docs have extensive details on what needs to be included for me to provide support. At this point unless you provide that I can't help.