OMV7 compose - saving a compose file spins up unrelated disks by df

fightforlife · Jun 28th 2024

Hello there,

after a long long time a switched back from my bare Ubuntu machine to OMV because I wanted something that just works and is mostly usable by webinterface.

So far everything works as expected. I am currently tracking down some reason why my harddrives spinup when navigating thtough the Webui.

On of the reason for waking up my sleeping drives is saving a compose file.

Everytime I save a compose file all my disk get a short access by a df command and all spin up. That is really annoying.

I have all my docker stuff on SSDs and I have not configured a backup.

Does someone know how to avoid this?

Code

root@server:/srv/dev-disk-by-uuid-b05244ef-501b-4f3a-95d0-846dfda36468# fatrace -c
df(94605): CO  /srv/dev-disk-by-uuid-b05244ef-501b-4f3a-95d0-846dfda36468
df(94647): CO  /srv/dev-disk-by-uuid-b05244ef-501b-4f3a-95d0-846dfda36468

ryecoaaron · Jun 28th 2024

When you save a file on the Files tab, it does the following:

writes to the omv database in /etc/openmediavault/config.xml
runs omv-salt deploy run compose (maybe saltstack is gathering info about the system and that causes the spinups?)
deletes the plugin's cache files in /var/cache/openmediavault

Otherwise, the Volumes tab executes a docker system df.

None of those steps are optional. I don't want to have the plugin try and detect if drives are sleeping and disable features. Mostly because it would break the plugin.

fightforlife · Jul 5th 2024

Hi ryecoaaron, thanks for your insight.

Steps 1 and 3 can not be relevant in this case since all docker config and the omv system are installed on the same SSD.

Ofcourse I do not want to have any additional checks for sleeping drives.

But I would like to find out why the command omv-salt deploy run compose is running df on all drives, even when they are never referenced in any Docker context.

The very strange part is, that I can only reproduce this when the drives are spun-down. Wehn they are spun-up, there is no access by df.

The only reference I found so far is the volumes as you already mentioned

openmediavault-compose/usr/share/openmediavault/engined/rpc/compose.inc at f8c6e386e12d7369c8cf94c35abefaf5ebf12735 · OpenMediaVault-Plugin-Developers/openmediavault-compose

openmediavault plugin for docker-compose. Contribute to OpenMediaVault-Plugin-Developers/openmediavault-compose development by creating an account on GitHub.

github.com

I will go on and do some testing.

ryecoaaron · Jul 5th 2024

Quote from fightforlife

But I would like to find out why the command omv-salt deploy run compose is running df on all drives, even when they are never referenced in any Docker context.

While the module being executed is for the compose plugin/docker only, that does not mean salt is doing docker context only. If you execute a sudo salt-call --local grains.items, that should be all of the salt grains that are collected when doing an omv-salt command.

jonebarker · Dec 20th 2024

I'm currently trying to mitigate this as I create and edit compose files several times a day. All data disks are SSD, but I have one HDD for rSnapshots that holds up my compose edits until spin up. Does anyone know if putting the backup disk on another NAS would solve this? I don't have another to test at the moment, but I'm eyeing a used Terramaster F2 or similar cheap dedicated backup box. But if its gonna wait for that too...then I'll just suffice without it.

ryecoaaron · Dec 21st 2024

Quote from jonebarker

Does anyone know if putting the backup disk on another NAS would solve this?

No. Look at bullet #2 in post #2. But with the latest compose plugin, simple edits are not running saltstack. Only new compose files are.

OMV7 compose - saving a compose file spins up unrelated disks by df

Participate now!

Tags