A RAM Disk will reduce the throughput load on your internal HDD/SSD. A few things to use a RAM Disk for include:
Besides having fast read/write speeds, a RAM Disk is great for extending your HDD/SSD’s usable life by placing the storage and I/O location of transient files directly into RAM; in some cases where it rightly belongs.
For Windows (10) the most stable utility to create a RAMDisk I’ve found is the open-source ImDisk Toolkit which you can find on SourceForge.
After you download and install ImDisk, fire it up and setup your disk size, label name, etc. I’ll leave you to read up and experiment but the overall usage is very simple and here is my configuration as an example:
That creates a drive
X:\ which lives entirely in RAM and is mounted at startup. Now let’s find some things to do with it!
If you’ve ever browsed the cache directory of Firefox/Chrome/Brave, etc. you would notice hundreds if not thousands of small files that make up the cached resources. These files are constantly being written, read, updated, deleted, and then re-written all over again resulting in a lot of I/O relative to other parts of the filesystem in terms of daily usage.
Specifying RAM as the location for cache won’t give you too much of a speed bump when rendering (unless your primary hard disk is magnetic) but it will do a few things:
To change the browser cache location in Firefox, type
about:config and hit Enter, bypass the usual warning and then Right-click anywhere in the list and select New String.
A window will popup asking you to input a preference name, simply type
browser.cache.disk.parent_directory and press OK, after which another window will popup asking you enter the actual string value. This is where you’ll enter the cache location. In my case I used the value
X:\FirefoxCache because I use multiple browsers, so I keep each of their caches in separate folders.
I use Brave as a daily driver and Chrome Canary mostly for testing (Canary installs itself explicitly as a non-default browser). Since both are Chromium based, the configuration is the same.
Setting the cache location for Brave/Chrome involves simply adding a flag to the executable when run as a shortcut. To do this simply right click the shortcut that you use (Desktop, Start Menu, Taskbar) and goto Properties and look for the Target setting.
At the end of the Target string you’ll simply add
--disk-cache-dir flag. As an example, here are my shortcut targets for Brave and Chrome Canary:
"C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application\brave.exe" --disk-cache-dir="X:\BraveCache"
Chrome Canary —
"C:\Users\paramdeo\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --profile-directory="Profile 1" --disk-cache-dir="X:\CanaryCache"
Because I use Incognito a lot (YouTube trailers, anyone?) I keep a separate shortcut that opens Canary directly in Incognito mode. This can be archived by using the the
--incognito flag, which specified that the browser is to opened in Incognito mode. Using my own setup as an example, I have a with the target set to
"C:\Users\paramdeo\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --incognito".
That being said, there’s really no reason for any files generated by the browser in an Incognito browsing session to be kept on disk. This includes both the contents of the Cache and User Profile directories. The custom Incognito shortcut simply has to additionally have the
--user-data-dir flags specified in order to change the location of these directories.
In my example I appended those flags to the entire custom shortcut resulting in a target of
"C:\Users\paramdeo\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --incognito --user-data-dir="X:\CanaryIncognito" --disk-cache-dir="X:\CanaryIncognitoCache".
Open the shortcut and then browse to your RAM Disk to see the folders being created and data being written there.
Cryptomator is a free and open-source tool that provides client-side encryption on the fly. If you haven’t used it yet, do yourself a security favor by heading to Cryptomator’s website and downloading it.
Cryptomator works by creating “Vaults” which are secured folders that you decrypt and mount as a regular drive or folder mount point. You can then work with data in these folders/drives as you normally would and in the background all data written to the vault is encrypted on the fly.
The generic use case for Cryptomator involves storing your documents in a vault, and keeping the location of the vault in a folder synced to the cloud, such as Dropbox. All of the data synced and stored in the vault within Dropbox is encrypted BEFORE being uploaded — thereby securing it from anyone who may gain access to your cloud storage, including Dropbox itself.
I use different Cryptomator vaults on a daily basis for documents, secrets storage, workspaces, projects, etc. Naturally it’s a good idea to mount these vaults in RAM; to avoid having the data be written twice (once to the mounted folder, and subsequently to the encrypted vault).
Achieving this is simply a matter of telling Cryptomator to use the a folder in the RAM Disk as the mount point.
By specifying a folder as a mount point, Cryptomator expects that the folder already exists when it attempts to mount a vault to that location. Cryptomator then transforms the folder to a directory junction while the vault is mounted.
The problem when using a RAM Disk is that the folder location is scrubbed when logging out. Therefore the folder will not be present at the next startup. Trying to mount the vault the next time around will result in an error unless you manually recreate the folder location each time.
The way I’ve gotten around this is by creating a startup batch script that creates a folder structure in the RAM Disk automatically when at logon. That way I can decrypt and mount the Cryptomator vaults without any trouble.
For reference, an example batch script would look like this:
That script is set as a simple scheduled task that runs at logon; pre-populating the RAM Disk with a folder structure that matches the Cryptomator vault names and therefore providing canonical locations for mounting.
I use Sandboxie now and then to run applications in an isolated manner for standalone binaries or portable apps such as Iridium Browser.
It’s fairly simple to edit Sandboxie’s configuration to use a RAM Disk for storing all of the user’s sandboxes — where Sandboxie mirrors Windows runtime files, application settings, downloads, etc.
To achieve this, open the main Sandboxie window and select the menu option Configure > Edit Configuration which will then open a text editor with Sandboxie’s configuration values.
[GlobalSettings] section, edit
FileRootPath to match the following:
In my case, I’ve set Sandboxie to store all User Sandbox files and data in the
X:\Sandbox RAM Disk folder, keeping the trailing environment variables that match the user/sandbox names intact. Sandboxie will now perform all of its intensive I/O operations within RAM ,instead of the internal disk drive.
In closing, this is what my RAM Disk generally looks like: