Software Encrypted SSD Performance – A Surprising outcome

Seriously? Are you surprised at the speed increase provided by an SSD?

No I’m not, actually I was a little disappointed in my SSDs Performance.

 

Did you buy a no-Brand SSD from some shady eBay seller?

Well, Kind of… I bought a Dell OEM branded edition of a Samsung PM830 from a reputable eBay seller… in person to avoid ebay charges for him, this drive is reported to be a High performance part by trusted sources. I then used Diskcryptor to provide protection against unauthorised access to my files from konboot, ntpasswd, linux live disks  or any other number of NTFS access based attacks.

Ahhh! I know what happened…. your SSD performance was limited by a less capable CPU that could only encrypt at low rate!

Actually, no the laptop hosting this drive has a recent model intel core chip that in benchmarks can easily encrypt twofish at a rate that could saturate the reported  550mb/s  max speed of this drive.

 

After some investigation and what seemed like an endless series of setting tweaks the issue seemed to stem from a problem that plagued the first generations of SSDs…. Wastage due to deleted flash memory blocks not being released cleanly back to the drive controller for reuse. This performance issue was overcome with the introduction of the TRIM command which ‘recycles’ deleted data blocks (explained here and here).

 

How did the Software based Full Disk Encryption (FDE) intefere with TRIM?

At a low level FDE intercepts file system operations from the Operating system to the Disk and turns them into what looks like random gibberish, so instead of a disk populated with nice sensibly structured file system the stored data  looks like nothing comprehensible until the appropriate encryption key is applied (these are usually derived from a password using something like PBKDF2).

 

This encryption provider that intercepts File system commands is where the performance degradation problem lies (at least in the case of diskcryptor) as it appears to interfere with the operation of the TRIM command.

This could be for many reasons but I would guess that the most likely culprit is that:

The  TRIM command issued by the Operating System (OS) provides a set of LBAs where files previously were deleted from, these blocks do not exist as a structure in the FDE container and mapping from the OS specified blocks to the FDE blocks can not happen due to various reasons related to the abstraction of the encrypted data on the SSD into a virtual HDD  (e.g potential storage errors due to  lack of discreet block level representation of files meaning that a TRIM command would wipe out a block of data  representing a segment of  the encrypted container and so would have a corrupting effect on subsequent data in that container) so the encryption provider may likely strip the TRIM command out to ensure integrity.

 

Should you not have known this?

I thought this would have been the case BUT there was so much anecdotal evidence on online forum sites stating that late editions of solutions such as Truecrypt and Diskcryptor would not  degrade performance on SSDs so I thought it was worth a check.

On initial encryption the performance was on par with its unencrypted throughput so I thought I had proven the online observations correct in this case.

My blind trust in the then ‘proven’ software solution is also why I spent a lot time looking @ other factors on my beta operating system before removing encryption especially as I installed an Intel chipset driver on this Win 8 edition around the time of the performance degradation and assumed a bug showed its face.

 

So is it a case of Speed or Security

Happily no, most modern SSD units support some form of strong encryption (e.g the PM830 has AES256, The Intel 320 has AES128 ) that can be ‘enabled’ (this is likely always on as there is no long initial encryption process) by adding a HDD password in the BIOS.

This has one major pro and huge negative:

Pro – The encryption is performed by the SSD controller so there is no host machine performance degradation due to the removal of an encryption overhead.

Con – The HDD password on the Samsung PM830 is 8 characters MAX, much weaker than my previous 37 character diskcryptor password (this is the reason I wanted to used a software approach in the first place).

 

So whats the outcome

Major laziness on my part came back back to bite me ,  I should have  checked the  performance of the software encrypted SSD  after filling and then removing data from it and not just shortly after I encrypted it and should not have assumed that the on-line anecdotes and my intital benchmark were correct.

Lesson learned and I am peeling the egg of my face but enjoying my again speedy SSD .

 


Comments

  1. Just a very general article, some bla bla bla, no real info. How much performance dropped? Does your processor support AES-NI? On i5 processor I benchmarked AES speed of 1,3 GB/s, much more than SSD speed. If you didn’t check that you have too slow processor, why do you blame SSD for it? It is like you installed propeller from small airplane to a rocket and blamed the rocket for being so slow with propeller…

  2. Hi Kleksu,

    Thanks for taking the time to look at my blog and write a reply.

    Yes this is a very general article as there are a few topics touched upon and it would take a long time for me to detail these facets more completely, this is intended to offer a recount of my experience to act as a warning\piece of advice to others (I am not a full time blogger, I have a Full Time job and am very busy so wont waste the time to produce the complementary articles).

    You make a great point about processors acting as a bottleneck for encrypted I/O operations but as I stated this computer has a recent model i3 and so has more than enough horsepower to keep the SSD operating at full capacity. Moreover on my initial encryption the SSD exhibited almost native performance so this was not due to having ‘a small propeller’, the degradation only kicked in after few months of use (or to be more accurate after I filled the disk a few times).

    That said if the CPU was a limiting factor it would more beneficial to encrypt such a disk using the on drive controller (actually this is always the case as this removes any host system penalty).

    When the disk was in its degraded state the speed was hovering around 100 mb/sec for sequential operations in crystaldiskmark and was abysmal for the 4k benchmarks.

    This article serves as a source of experience surrounding software encrypted SSDs for others to benefit from instead of blindly believing the anecdotal info found in places such as forum discussions which probably reflect the initial misleading performance profile of this type of scenario.

    Sadly I didnt record screenshots before the benchmark as I honestly thought this was due to a fault elsewhere and I am not going to thrash my SSD by reencrypting it with s/w and filling/emptying its drive to recreate the performance problem (and I dont have the time to do this)

    Thanks again for reading and engaging, this is very much appreciated :)

    If you have any other questions please ask away as I realise I may have skimped on some info in my haste :)

Leave a Reply

Your email address will not be published / Required fields are marked *

MIAp

Please type the text above: