Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] TrueCrypt with SSD



> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Chris O'Connell
> 
> Before encrypting the drive using trusty TrueCrypt I did a little
googling.
>  I found that full disk encryption significantly decreases performance.  I
> also found on TrueCrypt's website a statement telling users who have wear
> leveling drives (using TRIM) that TC should not be used.  TC claimed that
> their program could not be guaranteed to work properly.

Problem is:  Internally, all SSD's use 8k pages, and they map these
virtually into 4k blocks presented to the OS.  The nature of flash memory is
that you can write it once, and then it needs to be erased before it can be
rewritten.  So if the whole disk is encrypted and marked used (never TRIM'd)
then sure, write performance will degrade.  (Read performance does not
degrade.)  Every time you write a 4k block, the drive needs to read an 8k
block, overwrite 4k in ram, then write the whole mess to a new block, or if
there is none available, erase the block it just came from and then write it
there.

Drive overprovisioning solves a lot of that.  But presenting the OS with a
size that's smaller than the actual size, it ensures there is always some
amount of space available to avoid the above mentioned RMEW.  Some drives
allow you to specify how much to overprovision.  Internally the drive may
have 100G, but since the OS can only see 80G, that implies the other 20G are
actually free.  Can be erased, treated as if the OS had TRIM'd it.  

If you can overprovision more than 50% ... say 55% ... then you should
theoretically at least guarantee at all times there are some completely
unused blocks.  The disk controller could at least theoretically never need
to RMEW a single block ever.  Distribute all writes across 4k blocks in
separate and otherwise blank 8k pages.  No guarantee that any particular
drive is implemented to behave this way, unless you test it.

What OS are you running?  If it's windows, I see very little reason to use
Truecrypt or anything else over bitlocker.  But sure, there are situations
when other things have advantages over bitlocker.






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org