VeraCrypt
VeraCrypt copied to clipboard
veracrypt
Very bad performance on NVME SSD
Hi,
Please don't take that as a complain, I only wish to help improve the software so I can use it.
I achieve very bad performance on Windows 10 LTSB 2016 with a Samsung EVO 960 250Gb and Veracrypt AES encryption:
Before :
After :
My hardware :
I7 7700k @ stock 16Gb Corsair DDR4 Samsung 960 Evo 250Gb with up to date Samsung NVME driver Windows 10 LTSB 2016 up to date Veracrypt 1.19 64 bits
Veracrypt Benchmark :
How can I manage to get close performance to non encrypted drive ? Is this even possible ?
Thanks and best regards, Nicolas
It is problem not only for SSD. I got the same problem with 2.5'' SSD and HDD with hardware RAID0. Very low IOPS... 3-10 times less depending on hardware. Common symptom: writing is less affected than reading.
Due to this issue CPU speed does not make a lot of sense to estimate how fast disk encryption will be. So it would be very good if somebody can help to at least understand the reason.
UPDATE
I had to switch my storage system to DiskCryptor solution due to this issue.
It has approximately the same speed as unencrypted volume.
Hardware HDD RAID0 with on-board RAM cache gives me 10 times more read IOPS and +170 MB/s for linear read speed. Single SSD setup has 8 times more IOPS and + 90 MB/s for linear read.
So I can say it is 98% of "raw" speed.
The only drawback of DiskCryptor for me is no audits.
But I cannot accept so dramatic speed regression even if VeraCrypt is successor of TC and it was audited.
I read some opinions that TC was also slow on fast SSD disks. So I afraid it is some architecture problem initially created in TC.
Is there any news on this matter? It seems the iops still decrease drasticly.
@RcTomcat Unfortunatly I think it's not gonna change. If you want strong encryption it's the price to pay :/
No news on this task? I have the same problem:
Without encryption (Windows 10, samsung ssd 960 evo m2 500gb):
With encryption (AES, mounted file container)
As you can see in the screenshots - the speed is less than 10-20 times. read more
Are there ways to solve this problem?
I have the exact same issue, just on regular SATA SSDs.
DiskCryptor and BitLocker both perform very well (maybe ~5-10% decrease in the disk I/O), but performance with VeraCrypt is just abysmal. And yes, it is noticeable in normal workload, especially when operating on many small files at once. For this reason I have been using BitLocker for now (because DiskCryptor seems abandoned and does not support GPT).
I do not have top-notch hardware here but still... (AMD A10-7860K, 16GB RAM, 2 x SanDisk x110 256GB, Windows 10 LTSB 2016).
@304NotModified
Comparison of VeraCrypt and DiskCryptor on SSD:
As you can see, the performance is practically not degraded by DiskCryptor, but on VeraCrypt the performance drops in many times.
Click to view comparison of VeraCrypt and DiskCryptor on HDD
In order not to create a real HDD partition, I used a standard windows virtual disk real placed on single HDD:
The degradation in performance on single HDD is not noticeable.
Is there any effort to fix those ridiculous performance penaltys? Affect normal SSDs aswell not only NVMe ones.
I noticed the same thing on a new laptop I planned to encrypt. I've loved TrueCrypt and VeraCrypt for a while now, but due to time constraints had to buy BestCrypt. I hope the devs get this figured out.
@tomasz1986
because DiskCryptor seems abandoned and does not support GPT
Why do you need GPT if you do not have partition more than 2TB? Even large array are possible with RAID controllers (including integrated RAID). Just create 2 disks: 1st - MBR (for booting, small up to 2TB), 2nd - GPT (any size).
Why do you need GPT
GPT is required for disabling CSM, And disabled CSM is required for SecureBoot.
BUMP. Is this still an issue? Will using VeraCrypt FDE seriously drop write speeds down to 1MB/s? Is there a Fix?
Also how is Trim and Provisioning effected when software FDE is implemented?
I just encrypted my system drive with VeraCrypt (ver 1.23) on the almost identical HW configuration as listed in the first post. I see the same slow read speed in Samsung Magician and in CrystalDiskMark. Sequential read is down to 20% . Bitlocker compared to no-encryption is almost identical.
Now the good news. When I measured the real-time for programs to open, there wasn't much of a difference. Lightroom and Photoshop both take approx 2 seconds to be ready, just like with no encryption. Starting another windows 10 from Oracle VM VirtualBox takes 21.5 seconds with no encryption and 23 seconds with Veracrypt.
All programs are installed on my Samsung EVO 960 500GB and the startup time for each program is measured after a fresh system reboot.
I know it costs money, but I'm very happy with BestCrypt. Also, the older DiskCryptor works great for a MBR SSD if you don't mind disabling UEFI and all the modern settings.
Most people. We use Sophos Safeguard at work. Many use CheckPoint FDE. I build VPN's with Cisco, Fortinet, Palo Alto all day long. AES is a standard. Being open source is irrelevant.
Most people. We use Sophos Safeguard at work. Many use CheckPoint FDE. I build VPN's with Cisco, Fortinet, Palo Alto all day long. AES is a standard. Being open source is irrelevant.
Such tools like FDE, encrypting messengers and so on MUST be open source!
P.S. Let's stop flooding here.
I've just ran into the same problem. Unfortunately I can't see a solid alternative... Bitlocker isn't available on all Windows versions and DiskCryptor is dead.
Btw, does your SSD also show a disk activity of 100% when only writing about 20 MB/s with a response time of a couple of thousands ms? I do have this problem when moving things from a HDD to encrypted SSD.
bxkx, the people here would tell you not to use Bitlocker. Cuz it's not open source. sigh...
Plus bitlocker uses hardware-based encryption... which has it's own problems.
https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-encrypt-your-ssd-on-windows-10/
VeraCrypt tends to be slower for random read/write access because of its driver architecture and the way it handles IRP for I/O.
Because VeraCrypt supports file containers (which is not the case of DiskCryptor and Bitlocker), it can not handle IRPs in place and it must create a new IRP to the holding file for every read and which in turn causes a thread context switch. This explains the performance drop.
VeraCrypt uses the same IRP logic for both file containers and disks. Ideally, we should handle IRP in place for disks without context switch to have maximum performance and this requires a big architecture in order to keep both IRP logic working at the same time (a user can mount a file container and a disk simultaneously).
Some time ago I have implemented a prototype with a dual logic for file containers and disks but there was huge stability and reliability problems and I could find an easy solution for them.
Clearly the next version of VeraCrypt must address this and I hope there will be enough resources to work on this. Of course, external help is welcomed for such complex technical task especially that we want to keep file containers support.
It explains a lot, but regarding this:
VeraCrypt tends to be slower for random read/write access
All my above posts are about sequential read and write. So most likely it is also affected in some way by context switching. I am using Far Manager to measure real file reading (to nul device or to another physical disk).
Is there any update about the issue / an estimated release date for solving this issue? VeraCrypt is a great software and I would never trust Bitlocker in any way.
EDIT: So if there would be two different IRP paths the performance suffer would still exist for containers. So If you have for example a D: drive on a fast storage you should not create there a container and mount it, but instead encrypt the whole device and mount that for maximum performance. Right?
Bonjour @idrassi, based on your comment about IRP, what about having 2 separate "versions" of Veracrypt, one that supports both disk and file as you envision and one that implements IRP in place, supports only disk container and doesn't incur such performance loss. Users could then have the choice. I've been using Veracrypt with joy for so long but the more I invest in high-perf SSD the more I feel the pain of performance loss :( Would you give guidelines to potential contributors on where exactly to look in the code for such separate implementation? Or maybe the dual logic prototype you mentioned is indeed about that?
Agree with @daiveedx comment. It would be nice to have two versions or even better to have an option while installing VeraCrypt (to support file containers or not). @idrassi, what do you think? Thanks!
a user can mount a file container and a disk simultaneously
What about 2 instances in memory ? One for files and one for disks. Don't know much about driver development so I may be missing the ball entirely.
It's already three years and still no progress!!! Veracrypt:
-----------------------------------------------------------------------
CrystalDiskMark 5.1.2 x64 (C) 2007-2016 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 443.195 MB/s
Sequential Write (Q= 32,T= 1) : 401.027 MB/s
Random Read 4KiB (Q= 32,T= 1) : 44.960 MB/s [ 10976.6 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 87.532 MB/s [ 21370.1 IOPS]
Sequential Read (T= 1) : 442.259 MB/s
Sequential Write (T= 1) : 422.815 MB/s
Random Read 4KiB (Q= 1,T= 1) : 21.657 MB/s [ 5287.4 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 53.360 MB/s [ 13027.3 IOPS]
Test : 1024 MiB [H: 0.3% (0.1/19.5 GiB)] (x3) [Interval=5 sec]
Date : 2020/01/24 0:09:42
OS : Windows 10 Enterprise [10.0 Build 18363] (x64)
DiskCryptor:
Sequential Read (Q= 32,T= 1) : 539.805 MB/s
Sequential Write (Q= 32,T= 1) : 506.737 MB/s
Random Read 4KiB (Q= 32,T= 1) : 199.227 MB/s [ 48639.4 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 210.223 MB/s [ 51324.0 IOPS]
Sequential Read (T= 1) : 445.409 MB/s
Sequential Write (T= 1) : 457.458 MB/s
Random Read 4KiB (Q= 1,T= 1) : 34.845 MB/s [ 8507.1 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 78.314 MB/s [ 19119.6 IOPS]
Bitlocker:
Sequential Read (Q= 32,T= 1) : 535.229 MB/s
Sequential Write (Q= 32,T= 1) : 504.131 MB/s
Random Read 4KiB (Q= 32,T= 1) : 224.108 MB/s [ 54713.9 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 276.413 MB/s [ 67483.6 IOPS]
Sequential Read (T= 1) : 503.674 MB/s
Sequential Write (T= 1) : 466.702 MB/s
Random Read 4KiB (Q= 1,T= 1) : 32.395 MB/s [ 7908.9 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 78.547 MB/s [ 19176.5 IOPS]
Without:
Sequential Read (Q= 32,T= 1) : 537.022 MB/s
Sequential Write (Q= 32,T= 1) : 501.266 MB/s
Random Read 4KiB (Q= 32,T= 1) : 178.927 MB/s [ 43683.3 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 173.009 MB/s [ 42238.5 IOPS]
Sequential Read (T= 1) : 505.753 MB/s
Sequential Write (T= 1) : 470.623 MB/s
Random Read 4KiB (Q= 1,T= 1) : 38.418 MB/s [ 9379.4 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 78.865 MB/s [ 19254.2 IOPS]
As we see veracrypt sucks the most
