Posts by Cap10Canuck

    Good to hear!

    Sorry - just one last question - can I simply add another directory name to the table in the plugin to create a "custom ramdisk"? I also think I saw another post somewhere about using the "omvenv set <variable> <value>" command, where one of the environment variables specified a RAM based directory. Two ways to accomplish the same thing? My preference would be your plugin, if possible.

    Actually, i am going to release another version. The test script is really the problem. On really fast systems that complete the omv-writecache flush command in under 0.3 seconds, there isn't a lock problem but the test script reports it as one because the second run is allowed to run. I will release another package shortly.

    Tried your latest version and it works well now!

    Thank you.


    One quick question: Can you create a "personalized" cache by adding a directory name to the list in the plugin? Does that directory have to exist prior to adding it, or does the plugin essentially created a directory "in RAM" with the name you enter? My use case would be to enter a directory called "/transcode" which I can then pass to docker container like Plex or Jellyfin. Am I understanding the plugin properly?

    I saw "Write Cache" available as a plugin and installed it (after removing "flashmemory" and rebooting). All seems to be good, however when I run the "Test" option, the tests seem to pass, but then I get an error at the end. I copied the test results to a file (too long to add to a Code box)WriteCache Log.txt, not sure how to interpret them, but it looks like "concurrent_ops" is failing.

    The openmediavault-writecache plugin replaces openmediavault-flashmemory and was added to the omv-extras repository a few days ago.

    So it's as simple as disabling and removing the older flashmemory plugin, then installing and enabling the newer writecache one? Is it also safe to assume I can add a "custom" cached folder by adding the name in the list? For example, to be used by Plex/Jellyfin for transcodes?

    I know it doesn't help with your request, but after having frustratingly gone down the NVIDIA path for a long time, trying to get it to work with Plex, Jellyfin, etc., recovering/redoing my config after various Debian kernel updates, I gave up and bought a new server with a good Intel CPU (with imbedded GPU), and a NIC that is Intel and not Realtek. Since doing that and switching to the pve kernel, OMV and the 30 or so docker containers it hosts runs like a dream with almost zero intervention needed by me. Plex now simultaneously decodes/encodes multiple streams without skipping a beat.

    If your only option is an NVIDIA card, good luck. However, if you have ANY other option...

    An update for pve-firmware 3.15-2 showed up today. I used the GUI to update and I get the following error below. This is a fresh OMV install, I only use GUI for updates, have not installed any other packages via commandline, etc. Ideas?


    Currently running multiple docker containers that perform video transcoding (Plex/Jellyfin/Unmanic). I created a directory on a NMVe drive that is used for this purpose. It works, but I wonder if could work... faster.


    Looking at my RAM utilization, I easily have 24G+ of RAM that never gets touched (my system has 48G in total). Wondering if anyone has gone the RAMDisk route (for transcoding) with OMV7, if there would be any benefit, and if so, can I use OMV itself to create the RAMDisk, or would I have to use command line to create it and then mount via OMV.


    OR, should I just leave well enough alone as my system is humming along perfectly now! ;)

    Update:


    Using advice from ryecoaaron and Soma, I migrated my existing system to a fresh install on a (much needed) new Intel based server. Was going to run OMV in Proxmox, but when I looked at how I really use my server, OMV on bare metal better suited my needs. I can always use the KVM plugin to scratch my virtualization itch if needed.


    Prior to the migration I moved everything Docker related to the data disks and ran omv-regen. I did a fresh install on the new system (pve kernel this time!), transferred over the data drives, ran omv-regen regenera, and everything came up as before. Goodbye Nvidia graphics and Realtek NIC, hello Intel and Quicksync!


    This forum is great!

    OK - so I diligently attempted to follow all of the instructions above and in other areas of this Forum, alas to no avail - I was unable to move my docker storage location and have everything work afterwards.


    However... in the end, success! Shockingly, from Google Gemini of all places. For posterity and in case it might help someone else in the future, I thought I would reproduce the steps here. The biggest difference I see here compared to previous advice, is that "systemctl stop docker" did not actually stop any of my containers. I had to individually stop them using the OMV GUI.


    Forum admins - please feel free to delete this post if I inadvertently have provided bad advice. All I can say is that after following it, everything worked well afterwards, and my Docker storage is now independent of my system disk!


    1. Prepare the Data Disk


    Mount the disk: Ensure your data disk is properly mounted in OMV. You can do this through the OMV web interface under Storage > File Systems. Create a mount point for the disk, for example, /srv/dev-disk-by-id-yourdiskid. You could also just use an existing mounted file system.


    Create a Docker directory: Inside the mount point, create a directory to store your Docker data. For example, /srv/dev-disk-by-id-yourdiskid/docker.


    2. Stop Docker and Containers


    Stop the Docker daemon: Use the following command in the OMV command line interface (CLI) to stop the Docker daemon:

    Code
    systemctl stop docker

    Stop all running containers: Make sure all your Docker containers are stopped before proceeding. You can use the following command to list running containers:

    Code
    docker ps

    And then stop them individually using:

    Code
    docker stop <container_name_or_ID>

    3. Copy Docker Data


    Use rsync to copy data: It's essential to preserve file permissions and links when moving Docker data. The rsync command is ideal for this:

    Code
    rsync -aHv /var/lib/docker /srv/dev-disk-by-id-yourdiskid

    This command recursively copies all files and directories from the current Docker storage location (/var/lib/docker) to the new location on your data disk. The -a option ensures that permissions, ownership, and symbolic links are preserved. The -H option preserves hard links, and -v provides verbose output so you can see the progress.


    4. Configure Docker to Use the New Location


    OMV Web Interface: Go to the OMV web interface and navigate to Services > Compose > Settings.


    Change Docker storage path: In the "Docker storage path" field, enter the new path to your Docker data directory on the data disk (e.g., /srv/dev-disk-by-id-yourdiskid/docker).


    Save and Apply: Save the changes in the OMV web interface.


    5. Restart Docker


    Restart the Docker daemon:

    Code
    systemctl start docker

    Verify Docker: Check if Docker is running correctly and using the new storage location:

    Code
    docker info | grep "Docker Root Dir"

    6. Verify Functionality


    Start your containers: Start your Docker containers and ensure they are functioning as expected. This can be done in the OMV GUI


    Check container data: Verify that the data within your containers is accessible and consistent.


    7. Clean Up (only after you are positive everything is working!)


    Remove old Docker directory: Once you've confirmed everything is working correctly, you can safely remove the old Docker directory (/var/lib/docker) to free up space on your system drive.

    It looks like the realtek driver doesn't support the 6.12 kernel yet. As soma said, moving away from nvidia and realtek will make your life much better.

    I am planning a migration to my new server (reserving a weekend...), but in the meantime, to "restore order", would it be as simple as selecting the old "Debian GNU/Linux, with Linux 6.1.0-31-amd64" kernel as a default in the OMV Kernel GUI? These Realtek errors did not occur when that was the default kernel prior to the update.

    Are the builtin drivers in the 6.12 kernel not working?

    They are, as the server is fully accessible. Sorry my last post was not clear. I put that bit in because at the time I didn't realize you can disable the Update option of omv-regen. When omv-regen ran, it tried to do an update, and of course failed. I turned the option off and the backup ran well. As I am going to re-use the same drives in the new system, the Backup from omv-regen will be accessible.


    I am going to migrate my Docker folder from the system disk (on /var/lib/docker now) to one of the data drives, so I am hoping that i simply have to do a fresh install, move the data drives over and restore OMV on the new system.

    As soma said, moving away from nvidia and realtek will make your life much better.

    Agreed! My only snag is that omv-regen, as part of doing it's backup, tries to update OMV first (just saw option to negate this!!). Because of the Realtek driver/kernel issue, omv-regen quits when it encounters this error.


    Fingers crossed the Realtek drivers catch up with the kernel so I can do the migration!

    The only thing I have added that is perhaps outside the norm, is an Nvidia GPU. I followed the Nvidia install guide in the Forum to do so. Not a fan of Nvidia with Linux, but it was all I had for transcoding. There were actually some other recent issues with Nvidia drivers that I and others had.


    I coincidentally purchased another server yesterday, this time with an Intel processor and iGPU. Rather than waste people's time (like yourself!) for something that is probably an edge case, I am going to attempt to migrate my OMV setup to the new machine, Docker containers and all. To avoid bringing any issues over to the new machine i plan to do a fresh install and use omv-regen. My only worry is my 25 docker containers, but i am moving all disks (except system disk) from the old machine to the new one, so hopefully all will be well. I will search the forum for server migration advice.


    I was going to use Proxmox on the new machine and run OMV in a VM, but ryecoaaron convinced me in some of his other posts that bare metal was the way to go, and simply use the KVM plugin to play with virtualization!

    That's exactly how I did the upgrade - however during the upgrade process there were some errors, but I wasn't fast enough to capture them in the mini-window that pops up during an update.


    I thought I would try it again manually (using the wrong command line command apparently! Thanks for the correction.) because the gui now showed no updates , and that is when I got the failures. The failure mesage and log contents are in a post I created at the same time as the user who initiated this one, in the same forum. I used CODE boxes, at least! ;)

    I noticed that OMV was indicating there was an update pending this morning on the Dashboard, so I ran the update (via the GUI). Thought all was well until I SSH'ed into the server and tried "sudo apt upgrade". It said there were 4 packages, but the upgrade failed. See below.


    Sorry, but fixing the error is above my linux-pay-grade! Any suggestions?


    Contenst of /var/lib/dkms/r8168/8.051.02/build/make.log: