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 |
> 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 | |
We also thank MIT for the use of their facilities. |