Return to Level1Techs.com

Ramdisk on Linux that will move to a hard disk and back for reboots?

I’m still learning, but this is a place I trust to ask about things like this. I’ve been messing with making a ramdisk for an application and I was wondering if its not too hard to make it where the ram drive would be moved to a location on the hard drive when the application closes? For things like restarts and shutdowns, like when the power fails and the UPS takes over. Then when the application is started back up it’d create the ramdisk again and work from that? So not so much a back up on the hard disk like some guides want me to do, just kind of opening the application into a ramdisk automatically and doing the reverse when closing.

Does that make sense and is it feasible for someone like myself to set up? Thanks for any help.

I’m not sure entirely what it is you’re after, something like criu or just extra performance.

If latter, Linux has mlock and madvise that can force the app or mapped files to stay in pagecache (ram) while the app is running. Pagecache is also shared between processes.

Do you also want to force data writes to disk(or SSD/nvme) to not sync?

1 Like

Just for clarification:

You want to open the application -> kernel creates a ramdisk and loads application into that -> application lives in RAM until A.) Application is closed (writes ramdisk to disk in current state) and/or B.) Signal is received from UPS that power is funky and application is closed and then written to ramdisk?

This might be what you are looking for:

https://wiki.archlinux.org/index.php/Anything-sync-daemon

I did something similar to this with the .mozilla directory for firefox. When I would boot, it would copy the contents of the .mozilla file to /tmp ( which is tmpfs or ramdisk ) and copy the contents back to /home/{USER}/.mozilla, so this is very possible if you want to do it. I worked it out with a systemd unit file and timer. I did need to set up what the unit file depends on because of boot, shutdown, and a periodic timer as well to ensure a backup.

I’m using BOINC for [email protected], so I was concern about the data being saved properly. I wanted to be able to open BOINC and in doing so start it on a ramdisk, let it do it’s thing within ram, and if for any reason it needs to be closed (a restart , a power failure, anything) it’ll return to it’s place on the hard drive so no data is lost and it can continue from where it last left off. So I don’t need backups or restoration points so much, just the benefits of a ramdisk install without having to install every time.

I’m trying to let BOINC maybe gain some performance and reduce the wear and tear on my SSD. I know the latter isn’t much of a concern these days, but if I’m running it 24/7 I figure it’ll manage to cause some noticeable wear compared to normal use. I figure it’s not a beginner thing, but if someone had done it before I could at least try and follow the steps while changing a few things for my use case.

So you mean something like /var/tmp?

I’m not entirely sure to be honest. When i say “still learning” I really ought to say “still a beginner” because a good bit of the terminology is still going over my head even after googling it.

I just recalled that some time ago there was a Windows thing that did what I was thinking about. Initialized a ramdisk at start up (of the OS or the program, I can’t recall) and moved a directory or install from the hard disk to the ramdisk. Then when it was finished, the program closed or whatever, it was returned to the disk for safe storage. So the benefits of a ramdisk without losing anything after a restart/shutdown. I figured someone on Linux would’ve done something similar at some point, something I could follow. But if they have I haven’t found it or it just isn’t documented very well. I don’t really shut down my computer that often, so it’s not too much of a concern. But it was a nice-to-have sort of thing if it was easy enough.

The problem with that is if you have a power failure before the data can be written back to disk is a recipe for data loss.

2 Likes

That is true, I would hope my UPS would be enough to give the computer some time to return everything to disk. I just worry about the 100% chance of work being lost without being written back to disk versus maybe losing some work if it doesn’t make it in time. I may need more ram to do this either way considering how memory hungry Rosetta can be when it’s allowed to allocate what it needs.

Uh

I’m pretty sure thats sorta how… ram works?

2 Likes

Ah, what did I say? I feel I’m missing something.

It’s called “cache”.

The OS already caches disk access, at the block level. So hot PARTS of files can be in RAM (e.g., cache can be far more efficient than working with entire files), rather than doing dumb file copy/sync from location to location like with a RAM disk.

With modern OSes and big disk caches, the need for RAM disk just isn’t really there any more. The kernel uses a RAM disk during start up because it needs somewhere to un-pack to before it loads drivers to access disks, etc. if no disk drivers are available, it can’t do that to disk - so it uses RAM.

But that’s not for performance.

I’m only looking into it because Rosetta is writing about 10 gigs to my SSD over and over and over again throughout the day as part of it’s work. I figured containing it fully in RAM instead would help negate the damage, any performance gained to speed up the work would just be a bonus.

You don’t need to worry about SSD wear.

Google “ssd torture test” from a few years ago.

TLDR - writing FLAT OUT, 24/7 AT 100% WRITE LOAD on even 240GB SSDs from a few years ago takes several months to kill them.

2 Likes