salt on OMV5

  • I am testing OMV5 and I did notice quite a lot of 'salt' stuff and I assumed this was something new in Buster but I now think it is specific to OMV5.


    I wanted to find out a little bit more about how how salt is being used in OMV5 and if it is something I need to get more familiar with. I have done a quick google and tried a salt command but the salt-master package is not installed on OMV5 which surprised me.


    Is there anything that folks here can share in terms of how/why salt is being used in OMV5?


    Thanks in advance.

    • Offizieller Beitrag

    Is slower imo than old shell

    Depending on the platform, I've noticed that what used to take 2 to 15 seconds, may take up to 2 minutes in OMV5. Saying OMV5 appears to be 10x slower than OMV4, when saving configuration changes, in not an understatement.


    The change itself "seems" to happen immediately, but the GUI appears to be processing the change for a good while.

    • Offizieller Beitrag

    Sometimes is just the service restarting or doing other stuff besides writing config. But to measure the difference in between salt and shell you have to compare it In terminal running mkconf vs omv-salt deploy

    Regrettably, the actual speed of execution on the command line will not help the majority of users, who will be working with OMV5 in the GUI.

    • Offizieller Beitrag

    The change itself "seems" to happen immediately, but the GUI appears to be processing the change for a good while.

    Yes and no, having helped a user with a raid config his mdadm config was missing the reference to his raid array omv-mkconf mdadm is a much quicker than omv-salt deploy run mdadm.


    The gui 'slow' process seems to be when you have to 'apply changes' it's like watching paint dry :) and the salt commands and config are running in the background.

  • Thanks all. Interesting topic.


    I use OMV on a low powered boards (eg rock64) so the difference between OMV4 and OMV5 is massive when changing the config via the GUI.


    Once setup, I don’t change my config much but for users that do I can see this being a problem.


    @votdev when/where is websocket comm on the roadmap?

  • Thanks.


    I think there will be some users with RPI etc. that will have an issue with OMV 5 - in terms of performance - when applying setting changes. I suppose if you let users know this is expected behaviour then it might be ok...


    Is there anything that can take place in the background so users don't need to wait or is this too much of a change? Or even display some 'status' of activity on the form so users don't think it has crashed?


    For me this is a small issue and OMV5 is working great on my rock64 running the latest Armbian

    • Offizieller Beitrag

    hat will have an issue with OMV 5 - in terms of performance - when applying setting changes. I suppose if you let users know this is expected behaviour then it might be ok...

    This will not affect OMV performance as a NAS. It is only slow when making settings changes on slow devices. Most people setup their device and rarely make settings changes. So, I don't see this as a big deal.

    Is there anything that can take place in the background so users don't need to wait or is this too much of a change? Or even display some 'status' of activity on the form so users don't think it has crashed?

    The more you "update" a user, the slower it will get. It should tell you by displaying a real error if it crashed.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!