This project has moved and is read-only. For the latest updates, please go here.

Bad Write Speeds

Topics: Technical Issues
Feb 23 at 11:57 PM
Edited Feb 24 at 1:00 AM
I have one particular disk that seems to be suffering under Veracrypt. I have a total of 5 encrypted volumes, each on a different drive/array and each using the exact same encryption method - the other 4 work as expected and at very nearly full speed. The one goes from ~200MB/s writes to ~30MB/s with veracrypt. Removing encryption and reformatting the drive returns it to full speed.

This also applies to making an encrypted volume on the unencrypted disk. The write speeds are awful, but I can write to the unencrypted portion at full speed.

And two other interesting observations:
  1. Veracrypt encrypts the volume at 185MB/s with no error. It just writes to it slowly after the initial encryption.
  2. The Windows file copy utility writes to the encrypted volume at full speed. Nothing else I've found does, Teracopy, 7-zip, crystal disk mark, or any other benchmark I've found, Photoshop, etc... But the issue doesn't seem to appear with Windows built-in file copy utility.
Any idea what could be causing it?
Mar 4 at 7:13 AM
I've been completely unable to find any reason for the slowdown here. It's definitely related to the encryption/Veracrypt, but beyond that I'm at a loss.
Mar 4 at 7:42 AM
This is problem of internal structure. VeraCrypt and TrueCrypt works the same.
Sequence of any R/W operation of VeraCrypt in Windows
  1. System sends request to VC
  2. VC creates new request (IRP) and put it in queue for R/W thread.
  3. R/W thread perform operation(for small blocks) or schedule encryption to encryption threads.
  4. VC complete original request
Main problem is several threads switches. it can cause delays if there are many other active threads
Mar 4 at 8:53 AM
Edited Mar 4 at 9:16 AM
kavsrf wrote:
This is problem of internal structure. VeraCrypt and TrueCrypt works the same.
Sequence of any R/W operation of VeraCrypt in Windows
  1. System sends request to VC
  2. VC creates new request (IRP) and put it in queue for R/W thread.
  3. R/W thread perform operation(for small blocks) or schedule encryption to encryption threads.
  4. VC complete original request
Main problem is several threads switches. it can cause delays if there are many other active threads
Shouldn't that apply to all drives? The problem I'm seeing is that one specific drive out of 5 is operating at about 15% of its un-encrypted speed, whereas the others all operate at around 90% - and that it returns to normal (100%) speed when un-encrypted OR when reading from a VC container on the drive, instead of an encrypted partition.
Mar 4 at 9:28 AM
Post above describes possible reason. Might be there is another reason. Any thread related delays problems are difficult to reproduce. In most cases VC works normal but sometime threads switches can cause slow down. Low level disk controller can affect speed of R/W sequence also.