The Plugin aims to reduce the (write-) wear on your SSD(s) by incorporating the script(s) from @mgutt.

Upon the first array start, when the plugin is installed, it will move the docker status and log files into your RAM.*

A backup of the logs will be sync'd, to your appdata location every 30 minutes by default. You can change the interval from every minute to every 60 minutes on the plugins setting page (or set it to 0 to disable the automatic backup completely). It will also let you know, if the script applied the modifications or not.

If you happen to boot into a version of unraid which is not supported yet, nothing will happen. If the plugin then recieves an update, to support your version, a simple array stop and start will apply the necessary modifications.(i do hope im fast enough to update the plugin just in time so it runs uninterrupted, but im just human^^) 
All versions* should be supported now

*If you happen to find an incompatible one, let me know, unless its absolutely ancient

If you want to uninstall the plugin and remove the modifications, you would have to reboot your system  stop your array and then uninstall the plugin. This removes every modification done to the system. If you remove the plugin without stopping the array first, you have to perform a reboot. In the future, im planning to change the process and allow a more easy way of removal, that doesnt require a reboot, for now, its just an alleviation of manual checking, upon up and downgrading, if you used it in your go file before.


If youre curious on how it works, head over here:

*As long as you dont have a modified /etc/rc.d/rc.docker and/or /dynamix/scripts/monitor file

will have a look at that too

 

This should be resolved now.

Github:

https://github.com/Mainfrezzer/unRAID-RAM-Disk

 

 

Edited February 14, 20251 yr by Mainfrezzer
Update for new version

If we move to using the plug-in, we should remove any existing RAM-disk code from "/boot/config/go", right?

Edited March 3, 20251 yr by Phoenix Down

Yes, the go file is faster with applying code than the plugin is, which effectivly disables the plugin (for that specific unraid version).

Hey,

 

Recently updated from 6.12 to 7.0.1, was using the script since last year but found out about the plugin. I deleted the userscript, installed the plugin, stop/started Array and the plugin says its not running but the syslog shows the below. Also noticed that there's still small writes happening every 5-10 seconds. Thanks for all the work on this 

 

Mar 3 02:00:01 NAS-Gul docker: Success: Backup of RAM-Disk created.

Mar 3 02:30:01 NAS-Gul docker: Success: Backup of RAM-Disk created.

4 hours ago, Eoini1kenobi said:

Hey,

 

Recently updated from 6.12 to 7.0.1, was using the script since last year but found out about the plugin. I deleted the userscript, installed the plugin, stop/started Array and the plugin says its not running but the syslog shows the below. Also noticed that there's still small writes happening every 5-10 seconds. Thanks for all the work on this 

 

Mar 3 02:00:01 NAS-Gul docker: Success: Backup of RAM-Disk created.

Mar 3 02:30:01 NAS-Gul docker: Success: Backup of RAM-Disk created.

If i read that correctly, it seems like youre missing the reboot after deinstalling the userscript. Removing the user script doesnt remove the modification it has done to it.

You can quickly confirm that by looking into the syslog for 
 

Quote

RAM-DISK-Dockerlog Error: rc.docker is modified, possibly by the go file

 

Sorry, my bad, I definitely missed the reboot part, that error appeared before the RAM-Disk started every 30 minutes.

Is deinstalling the script as simple as removing it or do I need to run another script to do that before I reboot?

1 minute ago, Eoini1kenobi said:

Sorry, my bad, I definitely missed the reboot part, that error appeared before the RAM-Disk started every 30 minutes.

Is deinstalling the script as simple as removing it or do I need to run another script to do that before I reboot?

As long as you dont execute that script anymore (via go file or userscripts) and perform a reboot, its all gone. At the moment the script version of it is still running. 

reboot done, got a green tick and Success: Backup of RAM-Disk created in the log. However my SSDs are still doing writes and from what I see it's worse now, wheras before it was mainly kb writes every 5-10 seconds, it's now mainly MB writes under 5 seconds each time. No file activity or anything in the log to indicate what it's doing  

2 minutes ago, Eoini1kenobi said:

reboot done, got a green tick and Success: Backup of RAM-Disk created in the log. However my SSDs are still doing writes and from what I see it's worse now, wheras before it was mainly kb writes every 5-10 seconds, it's now mainly MB writes under 5 seconds each time. No file activity or anything in the log to indicate what it's doing  

This is just for the docker logs and health status checks, any container writing in appdata (like pihole to the database) or anywhere else on in their respective image will not be put into ram.

The intent is just to avoid write amplification by the logs and checks.

Lets say, one line of log (or health status check) is about 108 Bytes, it would write a total of 4KB on the ssd. Which is terrible because that happens every couple seconds for each container. If you have the backup enabled, it just writes all the logs that happened until that point once into the 4KB (if its less than that)

does having '--no-healthcheck --log-driver none' in the extra parameters of the containers stop those? Or is there any other way to stop them?

 

Thanks so much for your time on this

14 minutes ago, Eoini1kenobi said:

does having '--no-healthcheck --log-driver none' in the extra parameters of the containers stop those? Or is there any other way to stop them?

 

Thanks so much for your time on this

yeah that would achive the same, while disabling the healthchecks is generally not a problem, not having logs at all could be^^

so ultimately is there no way to potentially have prolonged periods of time where the SSDs could be inactive?

7 minutes ago, Eoini1kenobi said:

so ultimately is there no way to potentially have prolonged periods of time where the SSDs could be inactive?

with any docker container/vms or lxc container running, probably not. Unless its something as simple as a webserver. 

I can't find this plugin in CA. Does it need to be installed manually?

16 minutes ago, kennymc.c said:

I can't find this plugin in CA. Does it need to be installed manually?

 

It should be in there, it's certainly in the appfeed. Which unraid version and CA version do you have?

Just found it in the dropdown search results. Didn't show up when directly searching for ram-disk

2 minutes ago, kennymc.c said:

Just found it in the dropdown search results. Didn't show up when directly searching for ram-disk

Oh, you're right. I should add that to the search term. "Ram disk" would have worked 😄

Hello,

 

Can I change the folder for backup?

I want to put it in /dev/shm to be also in a ram drive. I don't care if the logs are deleted on reboot.

Can you make it as an option of the plugin?

18 minutes ago, sergiu.topan said:

Hello,

 

Can I change the folder for backup?

I want to put it in /dev/shm to be also in a ram drive. I don't care if the logs are deleted on reboot.

Can you make it as an option of the plugin?

im not quite sure why you want volatile backups of volatile files on the same machine. You can just set the interval to 0, which disables all the backup functionality and you achieve the same.

Although do be aware that without backups or that double RAM "backup" idea, any crash of the system will result in containers, that have been installed post array start, going missing, since theres no information about them.

The whole backup is basically just a "docker integrity" mechanism that at worse, you only use an hour of changes.

I thouth that this will move only the logs to the RAM.

2 minutes ago, sergiu.topan said:

I thouth that this will move only the logs to the RAM.

 

it does, but docker relies on information of that folder. Im not absolutely sure how exactly the docker mechanism works but if it doesnt find the containers related folder in there, docker wont display the container. its still technically installed, but docker knows nothing about it

@Mainfrezzer Since the docker rotation targets where docker believes the files are (which will always be RAM, before it gets dumped to the SSD), does this create a potentially forever increasing log backup in the SSD?

If it does it based on the log name (meaning it replaces/overwrites the SSD file), does that then mean that you can only ever have one set worth of logs (rather than having potentially days of logs except the last 30 minutes for example.

7 hours ago, AuroraStarstorm said:

@Mainfrezzer Since the docker rotation targets where docker believes the files are (which will always be RAM, before it gets dumped to the SSD), does this create a potentially forever increasing log backup in the SSD?

If it does it based on the log name (meaning it replaces/overwrites the SSD file), does that then mean that you can only ever have one set worth of logs (rather than having potentially days of logs except the last 30 minutes for example.

No the files are just being kept in sync. they do not increase forever or get appended or something.

with or without the plugin, the max log size for each container is based on this setting

So if you have an extremly spammy container, the log might be 3 hours before it rotates, if its a quiet container, you could look at weeks.

On 12/17/2025 at 8:12 AM, Mainfrezzer said:

No the files are just being kept in sync. they do not increase forever or get appended or something.

with or without the plugin, the max log size for each container is based on this setting

So if you have an extremly spammy container, the log might be 3 hours before it rotates, if its a quiet container, you could look at weeks.

If the files get overwritten at the SSD with the newest set from RAM at a given interval does that mean that there's no point in creating separate log files (Usually you'd want many small files rather than one big so you delete less when it rotates and you don't have to crawl through the entire log if you know something your looking for happened in one)?

Just checking in, is this plugin still relevant today with 7.2.4? Last update was from over a year. Did Unraid in the meantime improve this?