📅 February 17, 2017
“Can I use RapidDisk with VeraCrypt?”
Absolutely. If you have an encrypted volume with VeraCrypt, you can easily add a RAM cache to improve read performance.
The setup is the same as with a regular RapidDisk cache but with an added extra step to map the VeraCrypt volume.
This article will assume that you are already familiar with RapidDisk and how to set it up on your system in Linux Mint 18.1. If not, the other article will provide more details. Let us also assume that we have a hard drive that is already encrypted with VeraCrypt. The type of VeraCrypt encryption does not matter as long as it is an encrypted volume.
The idea is to create a RAM cache for the encrypted volume that VeraCrypt will decrypt. However, we want to make sure that the cache only contains encrypted data, not plaintext. Think of the flow as a chain, so we want to map the cache to the hard drive but let VeraCrypt decrypt the cache. This way, the cache only contains encrypted data.
sudo rapiddisk --attach 6144 sudo rapiddisk --cache-map rd0 /dev/sda veracrypt /dev/mapper/rc-wt_sda /media/datamount
For this example, suppose we have the encrypted hard drive /dev/sda. The entire device is encrypted. We want to mount it with a RAM cache at the mount point /media/datamount.
1. Create the RAM cache
sudo rapiddisk --attach 6144
This creates a 6GB RAM disk, so make sure you have enough RAM or modify the size to suit your needs. If this is the only RAM drive on your system, then it should start with the name rd0. Enter sudo rapiddisk –list to double check the RAM drive names.
2. Map the cache to the encrypted hard drive
sudo rapiddisk --cache-map rd0 /dev/sda
rd0 is the RAM disk in this example. Yours might vary. Keep in mind that when we access rd0 in the veracrypt step below, we will need to use the full path /dev/mapper/rc-wt_sda.
How do we find that rd0 is /dev/mapper/rc-wt_sda? Enter sudo rapiddisk –list after the mapping is complete and look for the “List of RapidDisk-Cache mapping(s)” section in the result. There should be a line that looks like this:
RapidDisk-Cache Target 1: rc-wt_sda Cache: rd0 Target: sda (WRITE THROUGH)
/dev/mapper/rc-wt_sda is what VeraCrypt needs. If we enter sudo fdisk -l, we will see that /dev/mapper/rc-wt_sda is recognized by the system.
3. Mount with VeraCrypt
veracrypt /dev/mapper/rc-wt_sda /media/datamount
This part is standard with VeraCrypt, so you might need to enter your password or use custom options for your situation. The point to note is that we use the RAM cache device /dev/mapper/rc-wt_sda (or whatever yours might be) and NOT the encrypted hard drive /dev/sda.
How Fast is It?
Are there any speed improvements?
Yes, but results vary according to the size of the data and the speed of the decryption system.
I performed this test using a standard mechanical hard drive that was encrypted with VeraCrypt. A point to note is that VeraCrypt’s encryption/decryption speed depends upon the speed of your CPU. You can use VeraCrypt’s built-in benchmarking tool to find out how fast VeraCrypt performs on your system. This speed affects the caching performance.
Here are a few benchmarks from Disks in Linux Mint 18.1. Since RapidDisk only caches reads, I did not benchmark the write performance.
What About File Transfers?
Benchmarks are fine for a performance overview, but what about a real-world file copy?
I copied a set of Linux Mint ISO images totaling 3.7GB from the encrypted hard drive to home located on a fast M.2 SSD to avoid any bottlenecks in the chain. The test (a timed copy) was executed four times in a row to gauge the cached read performance.
The first read from the hard drive took 26.6 seconds (real) while subsequent reads took about 8 seconds each since the 3.7GB data was cached.
Small Files = Fast, Large Files = Slow
A point of observation that repeats with RapidDisk is that cached small files ~1MB read very fast. Often in the 1.1GB/s range or higher. Larger files tend to reduce the caching effectiveness.
In the 5x1000M Disks benchmark above, RapidDisk only offered an improvement of ~200MB/s for cached reads. While this is better than the hard drive’s limit of ~120MB/s throughput, it is not the RAM-level improvement of ~3-8GB/s that I was expecting.
When you think about it, this makes sense. If files are small enough to store completely in RAM, then reads are very fast, but as the files grow larger or exceed the RAM cache limit, then data must be retrieved from the slower hard drive. This results in less noticeable read performance.
On the plus side, access times were much shorter for all file sizes.
What If We Switch RapidDisk and VeraCrypt Around?
Will it work if we put the RAM cache at the end of the chain instead of VeraCrypt?
Yes, it will work, but I encountered two drawbacks:
- The RAM cache contained plaintext. If you use VeraCrypt to decrypt before accessing the RAM cache, then cached data can (potentially) be viewed if analyzing the cache.
- Performance was slower. For some reason, VeraCrypt between the hard drive and the RAM cache resulted in slightly slower reads than the numbers shown in this article. Placing VeraCrypt at the end of the chain (after the RAM cache) and allowing it to decrypt the cache resulted in faster read performance.
RapidDisk + VeraCrypt works, and it runs well! I have had no problems (so far). All data writes to the hard drive, and I have not experienced any data loss. Subsequent reads improve.
Hard drives often include cache, but it tends to be small at ~64MB. RapidDisk allows you to expand a hard drive’s limited cache into a larger, custom size for better performance.
Is the lower read caching performance for large files a disadvantage? Not really. A RAM cache is a huge benefit for certain areas, such as a web server that must supply many, many small duplicate files to many, many users who access the site. In this case, a RAM cache can offer a significant advantage.
If you wish to squeeze a little more performance out of your encrypted hard drive system, then RapidDisk and VeraCrypt make a good team.