_whatever

While this docker container works great on Unraid, if you're using it on a drive formatted with Btrfs, you might be killing your drive(s). A couple of months ago I gave my son my TP-Link OC200 for this apartment setup and I decided to replace it with this docker container on my Unraid server. The other day I noticed that my cache drives, where the docker data lives, had unusually high numbers of writes accumulated, and after using iotop I saw the biggest contributor was mongod, followed closely by btrfs-transacti. Then a lightbulb went off in my head. I remembered reading some time ago about the gotchas of Btrfs and workloads with a lot of random writes (databases) causing excessive fragmentation and thrashing discs. This excellent post on the MongoDB community forums explains the issue very well. So I was left with 3 choices in that moment: Upgrade my Unraid license so I could add an XFS formatted drive for the Omada controller data. Remove one of the drives from my mirrored Btrfs array and make it a standalone XFS drive for the Omada controller. Figure out a way to retroactively turn off CoW for the MongoDB data. Since I was pressed for time (and money), option 3 seemed best, so that's the route I went, using these great instructions on the Arch Wiki. Because I had been previously bitten by the loopback write amplification bug with in Unraid 6.8 I had switched from using a docker image to having docker write directly to disk. This made things a little bit easier since I had direct access to the database. So I stopped the docker service went to the terminal, renamed the db folder in /mnt/cache/appdata/omada/data to 'dbold', created a new folder named 'db' and added the +C attribute, then used cp to recursively copy everything from dbold to db using the --reflink=never switch. Started the docker service back up and kept my fingers crossed. So far the number of writes does seem to be down considerably. I'll keep an eye on it over the next few weeks to be sure. My long term plan is to rebuild my server soon anyway b/c these drives are REALLY old SATA SSDs from like 2017. So once I get to that point I'll probably switch to NVMe for cache and dedicate a cheap SATA drive formatted XFS for anything with a database workload, just to play it safe. YMMV.

Perfect. Thank you!

It looks like this container has quite a few vulnerabilities, including log4j. I was just curious if @Djoss had plans to update the container before I try to update the contents of my container to mitigate the issues, and hopefully not break anything. Thanks. https://try.trivy.dev/results/mLA3h91Jqqx14ZibyMYnx3mG

For others coming from 3.2 you can use the link below to migrate your config. Note, you'll have to reconfigure any ACLs or captive portals you have setup since they won't migrate. You also have to make sure that the paths for your data, work and logs folders all point to a single disk and not a share. In my case I'm using /mnt/cache/. https://www.tp-link.com/us/omada-sdn/controller-upgrade/#content-5_1_2 Skip to bullet 2 step 1.

I just kept the stock default config and ran through the wizard and then imported my config from the old controller. Seems to have worked fine. Thanks for your work on this container so I can use a much newer version!

Just out of curiosity, do you know if on first run this will upgrade a 3.2 database if I copy over my config and db from a 3.2 install and use it with this container? I was going to try it later but thought I'd ask first in case it's a waste of time.