The omada controller is run on a variety of devices, some of which may not have storage systems which can handle large amounts of writes.

I was curious about reducing the write operations of the Omada Controller and I figured starting a thread would be handy.

On my 3.2.4 installation, I rebooted the controller and monitored the disk usage for about 8 hours, and there is definitely disk activity (overnight was about 100MB across omada and mongodb).

I will noted that I have already tried to disable the mongodb journaling in an effort to reduce the writes.

Warning - disabling Journaling comes at a risk of database corruption if there is a system failure - so consider your use case.

It think changing it was pretty:

in /opt/tplink/EAPController/properties/mongodb.properties change the linux.mongod.nojournal entry to true

##disable mongodb journaling in linux
linux.mongod.nojournal=true
 

Note, my copy of the file looks like it was written with MSDOS carriage returns...someone using a Windows text editor?

Other sources of writes are most likely the log files and the mongodb.

@R1D2 has already identifed a the omada logs are in /opt/OmadaController/logs and suggested using an tmpfs which is probably the way to go.

That said, I suspect the majority of writes go to /opt/tplink/EAPController/data/db

If journaling is enabled, this area was about 3GB+ on my installation. So putting that in tmpfs may require considerable amounts of memory.

By disabling journaling, the disk space of my database is down to 200MB, which is more feasible on my system.

To help manage keeping the database alive over system reboots, I have had some luck with using persist, which is a syncable ramdisk service on debian.

I'll play around with it and post here if I manage to make any progress!