When changing the MergerFS Create policy in the OpenMediaVault GUI and clicking Apply, OMV updates its stored configuration and generated mount configuration, but an already-running MergerFS pool may continue running with the previous policy.
This results in a discrepancy between what the OMV GUI reports as configured and what the active MergerFS filesystem is actually using.
In my case, the MergerFS pool was originally configured with:
Create policy: Existing path, most free space (epmfs)I later changed the policy in the OMV GUI to:
Create policy: Most free space (mfs)The OMV configuration correctly showed mfs, but the already-running MergerFS process continued using epmfs.
Environment
- OpenMediaVault 8
- Raspberry Pi 4
- MergerFS 2.42.0
- Five-drive MergerFS pool
- Pool name:
5bay
What happened
After changing the MergerFS Create policy from epmfs to mfs in the OMV GUI and clicking Apply, the GUI showed the new mfs configuration.
The OMV configuration database also showed:
"createpolicy": "mfs"/etc/openmediavault/config.xml likewise showed:
<createpolicy>mfs</createpolicy>The generated systemd mount unit also eventually contained:
category.create=mfsHowever, the currently running MergerFS process was still using:
category.create=epmfsThis was confirmed directly from the running process:
sudo tr '\0' ' ' < /proc/$(pgrep -f 'mergerfs 5bay:' | head -n1)/cmdlinewhich returned, among other options:
category.create=epmfsTherefore, the GUI and stored configuration indicated mfs, while the active filesystem was still operating with epmfs.
Why this is a problem
This is particularly significant for MergerFS because the Create policy directly affects which underlying filesystem receives newly created files.
An administrator can therefore:
- Change the policy in the OMV GUI.
- Click Apply.
- See the new policy displayed in OMV.
- Reasonably assume the pool is now operating with that policy.
- Continue a large data migration.
- Actually have the migration running under the previous policy.
This can result in data being physically distributed across the underlying disks differently from what the administrator intended.
In a storage-management system, this discrepancy is especially difficult to detect because the GUI appears to indicate that the change has already been applied successfully.
Expected behavior
When the user changes a MergerFS pool configuration and clicks Apply, OMV should ensure that the active MergerFS mount is recreated/remounted with the new configuration.
For example:
GUI configuration change ↓
Click Apply ↓
Update OMV configuration ↓
Regenerate MergerFS mount configuration ↓
Safely unmount affected MergerFS pool ↓
Remount pool using new options ↓
Verify mount is activeAfter clicking Apply, the running MergerFS process should use the same policy shown by OMV.
In this particular case, changing:
epmfs → mfsshould have resulted in the active MergerFS process immediately using:
category.create=mfsSuggested behavior for busy pools
I understand that automatically remounting a filesystem can be unsafe if the pool is currently in use.
If OMV cannot safely remount the pool because it is busy, it should instead explicitly report that the configuration change has not yet been applied to the active mount, rather than silently leaving the old policy running.
For example:
Quote"The MergerFS configuration has been changed, but the active pool could not be remounted because it is currently in use. The new configuration will not take effect until the pool is remounted."
An explicit "Remount required" state would also be acceptable.
Workaround discovered
In my case, manually stopping and starting the generated systemd mount caused the running MergerFS process to finally adopt the correct policy:
sudo systemctl stop srv-mergerfs-5bay.mount
sudo systemctl start srv-mergerfs-5bay.mountAfter restarting the mount, the active process correctly reported:
category.create=mfsThe generated mount unit also contained:
category.create=mfsWe then performed an actual file-creation test through the MergerFS mount and confirmed that the file was created on the expected underlying filesystem.
Proposed fix
I believe the most appropriate fix is for Apply on the MergerFS configuration page to automatically reconcile the active MergerFS pool with the newly applied configuration.
At minimum, OMV should detect when a configuration change affects the active MergerFS mount and either:
- Automatically remount the affected pool, or
- Clearly indicate that the configuration is pending and that the pool must be remounted before the change is active.
The important point is that the OMV GUI should not present the new MergerFS policy as fully applied while the active MergerFS process is still operating under the previous policy.
Additional note
I believe this is primarily a configuration/runtime synchronization issue, rather than a MergerFS bug itself. MergerFS correctly continued operating according to the options with which its existing process had been started.
The issue is that OMV allowed the persistent configuration, generated configuration, and GUI state to diverge from the active runtime state without clearly communicating that the existing MergerFS process had not adopted the new settings.
Because this can affect actual file placement on a storage pool, I believe it warrants consideration as a bug or usability/safety issue in OMV's MergerFS integration.
im unsure if this is intended behavior but i wanted to make this known so others were aware not to depend on the GUI if you change the policy in the pool after already having one set.
