|
chizad posted:I'm also running BitLocker on my laptop, but I'm not sure how much of a drop in performance that would account for. This pretty much explains those numbers. Software encryption is a massive I/O hog. While the impact might not be felt as much using a SSD over a HDD, side by side benchmarks generally see a huge hit in I/O performance with it turned on. Over time on a crappy SSD to boot, you get sad, sad numbers like those. I'm not sure if the free space is encrypted with Bitlocker (might) but if that drive is sitting at 100% used internally, even the best garbage collection on the planet won't save it at that point.
|
#
?
Mar 12, 2012 17:41
|
|
|
|
| # ? Apr 29, 2024 13:51 |
|
|
Bullshit. I ran TrueCrypt FDE on a 64GB Kingston V100 with an AMD E350 APU - hardly beefy in any sense - and I still only had a 20% drop in sequential I/O and no drop in random I/O. That drive is seeing well over an 80% drop in sequential, over 90% in 512K random, and 75% in 4K random for writes.
|
|
#
?
Mar 12, 2012 18:02
|
|
|
Factory Factory posted:Bullshit. I ran TrueCrypt FDE on a 64GB Kingston V100 with an AMD E350 APU - hardly beefy in any sense - and I still only had a 20% drop in sequential I/O and no drop in random I/O. That drive is seeing well over an 80% drop in sequential, over 90% in 512K random, and 75% in 4K random for writes. Yea but we aren't talking about a installed it one day and ran benchmark right after on a modern SSD with TRIM. We are talking about long term performance degradation with ancient GC and no TRIM support. EDIT: Decided to play around with this. Not sure if I should have picked the fastest SSD in the box or the worst to show some examples of before/after with TrueCrypt and BitLocker... but I settled in on a SSD 520. TC AES was pretty painful, going to redo some stuff when I have enough time to blow, but read speeds dropped from ~480 to 330MB/s and write speeds down from ~300MB/s to about 8MB/s. Not sure if it was the SF processor needing some settling action after the new full partition dropped in place but it was making GBS threads itself. Mind you this is on a DX79SI Intel board with an Intel 3960X EE processor and 64GB of RAM, so this isn't an underpowered system in the slightest. Want to see how much software encryption destroys SSD performance?   
dietcokefiend fucked around with this message at 20:12 on Mar 12, 2012 |
|
#
?
Mar 12, 2012 18:25
|
|
|
Does anyone know how to force a drive to be a certain drive letter? I encrypted my program files drive, which was formerly E:\ but will now come up as something else when truecrypt mounts it. It's mounted as a system favorite, so it mounts before windows loads.
|
|
#
?
Mar 12, 2012 19:06
|
|
|
Clanpot Shake posted:Does anyone know how to force a drive to be a certain drive letter? I encrypted my program files drive, which was formerly E:\ but will now come up as something else when truecrypt mounts it. It's mounted as a system favorite, so it mounts before windows loads. Once windows loads you should be able to go into computer management and change the drive letter and that should stick. Does the letter at least stay consistent or does it bounce around each time depending on what else is plugged into the system?
|
|
#
?
Mar 12, 2012 19:10
|
|
|
dietcokefiend posted:Once windows loads you should be able to go into computer management and change the drive letter and that should stick. Does the letter at least stay consistent or does it bounce around each time depending on what else is plugged into the system?
|
|
#
?
Mar 12, 2012 19:27
|
|
|
Clanpot Shake posted:I'll give that a go when I get home from work. How does windows disk manager work? By SATA connection, or drive serial? I might shuffle things around in my case and it'd help to know. I've always seen it give priority by SATA/SAS connection although things as retarded as thumbdrives or USB card readers connected on boot can screw that up.
|
|
#
?
Mar 12, 2012 19:30
|
|
|
dietcokefiend posted:Want to see how much software encryption destroys SSD performance?
|
|
#
?
Mar 12, 2012 20:19
|
|
|
If you need FDE buy a self-encrypting drive.
|
|
#
?
Mar 12, 2012 20:40
|
|
|
Clanpot Shake posted:Does TrueCrypt normally destroy performance like this? I was under the impression modern chips could do encryption via hardware. What's the takeaway on encrypting SSDs? The takeaway is only use the drive's built-in FDE encryption. Many SSDs can handle this internally with zero performance impact. The downside is you generally need to turn on a BIOS password to enable it on a consumer platform, and you are limited on password length. I think a Dell XPS 9000 I tried it on once limited you to like 5-6 characters. SandForce models and others literally don't care if you enable it or not, since they are using it internally regardless. One has a user-set key, the other just uses a default key. Swapping them out makes the controller work no harder or less. The primary difference is when the controller knows what is going on, it can still pass TRIM, leave open space for GC, and not have to worry about encrypting the unused NAND needlessly. The problem like I mentioned before is when done through software if you do FDE (using entire drive surface) you leave the controller zero room besides what little over-provisioning the drive had from the factory. It can barely do GC, and TRIM is meaningless at that point. I suppose if you only did like 80% of the drive surface the performance would be better, but it would still be a massive letdown if you purchased a brand new SSD and installed software encryption. The only car analogy I could come up with would be like buying a brand new M5 and removing the tires  evil_bunnY posted:If you need FDE buy a self-encrypting drive. Pretty much. Lots of consumer models support it already (any SandForce drive, Intel 320, list goes on)
|
|
#
?
Mar 12, 2012 20:40
|
|
|
I've got an Intel 510. Is this limited to the 8 character BIOS password, and is there a guide I can read about setting it up? Using the built in FDE is all well and good, but I need my Program Files drive to mount also before windows even starts. I don't know of a way to do this without using TrueCrypt.
|
|
#
?
Mar 12, 2012 20:53
|
|
|
Clanpot Shake posted:I've got an Intel 510. Is this limited to the 8 character BIOS password, and is there a guide I can read about setting it up? Hardware FDE does it at BIOS load... so well before the system even cares about loading Windows at that point. TrueCrypt has a bootloader as well, that does it right after the BIOS loads and before Windows starts to load. Now the sad news is the Intel SSD 510 doesn't support hardware encryption. The Mavell controller inside of it doesnt have that feature. 
|
|
#
?
Mar 12, 2012 21:00
|
|
|
Welp. I'll give this TC setup a go for a while and see how it goes. Thanks for the help.
|
|
#
?
Mar 12, 2012 21:01
|
|
|
Clanpot Shake posted:Welp. I'll give this TC setup a go for a while and see how it goes. Thanks for the help. Do you have Windows 7 Ultimate by chance? Bitlocker will offer much nicer speeds.
|
|
#
?
Mar 12, 2012 21:02
|
|
|
dietcokefiend posted:Do you have Windows 7 Ultimate by chance? Bitlocker will offer much nicer speeds.
|
|
#
?
Mar 12, 2012 21:04
|
|
|
Clanpot Shake posted:I do, but that still doesn't solve the problem of mounting my secondary drive before loading windows (unless bootlocker can do that too). When TC decrypts a drive the last step is to remove the TC bootloader. EDIT: Just looked at the wording, and it says it will automatically unlock the secondary drive at windows login. So for that you might be screwed. Are the programs seperate from the files you need to encrypt? IE make two partitions... one for the software, one for the sensitive data? dietcokefiend fucked around with this message at 21:13 on Mar 12, 2012 |
|
#
?
Mar 12, 2012 21:08
|
|
|
dietcokefiend posted:EDIT: Just looked at the wording, and it says it will automatically unlock the secondary drive at windows login. So for that you might be screwed. Are the programs seperate from the files you need to encrypt? IE make two partitions... one for the software, one for the sensitive data?
|
|
#
?
Mar 12, 2012 21:22
|
|
|
Clanpot Shake posted:The drive contains my user profile (My Documents, Downloads, etc.) as well as most installed programs, like Firefox. I consider all that saved form information (CC number, for example) sensitive data, so I'd like the whole thing encrypted.
|
|
#
?
Mar 12, 2012 21:30
|
|
|
dietcokefiend posted:EDIT: Decided to play around with this. Not sure if I should have picked the fastest SSD in the box or the worst to show some examples of before/after with TrueCrypt and BitLocker... but I settled in on a SSD 520. I did a quick before/after test with BitLocker on a system identical to mine. It looks like the performance hit from BitLocker (especially writes) on this particular drive is absolutely brutal. Clean Windows Install, BitLocker Off Sequential Read/Write: 197.0 / 157.6 512K Read/Write: 162.7 / 56.53 4K Read/Write: 16.15 / 5.77 4K QD=32 Read/Write: 20.97 / 3.073 Clean Windows Install, BitLocker On Sequential Read/Write: 155.8 / 16.78 512K Read/Write: 132.3 / 3.368 4K Read/Write: 12.61 / 2.572 4K QD=32 Read/Write: 18.95 / 0.406 evil_bunnY posted:If you need FDE buy a self-encrypting drive. Since I'm in the IT department a self-encrypting drive wouldn't be a big deal for my usage and wouldn't cause too many headaches for my coworkers if something happens and they need data from my machine. But I cringe at the support nightmare that would ensue if we deployed drives with hardware FDE to all of our users that handle sensitive data instead of BitLocker. We've got it set up so that any system we enable BitLocker on automatically backs up the recovery information to Active Directory so we can get to it at a moment's notice.
|
|
#
?
Mar 13, 2012 00:15
|
|
|
chizad posted:I did a quick before/after test with BitLocker on a system identical to mine. It looks like the performance hit from BitLocker (especially writes) on this particular drive is absolutely brutal. Yea anyone who thinks software encryption doesn't affect performance is kidding themselves or is just oblivious to the differences. My example was one of the fastest consumer models on the fastest consumer hardware platform. People constantly look at CPU overhead and sequential encode/decode performance instead of standard disk benchmarks when looking at disk/file encryption packages.
|
|
#
?
Mar 13, 2012 00:34
|
|
|
How does that compare to filesystem encryption in Linux? Speed-wise, that is. I checked the box 'encrypt my system' in lubuntu, I have to enter a password when I boot to read the drive.
|
|
#
?
Mar 13, 2012 01:05
|
|
|
Oh, I bet I know what the software FDE difference is that let me have good performance: fill the free space of the drive with a random-data junk file, then delete it to force a TRIM across the free space. That will re-sync the controller's idea of what's unallocated with the OS's.
|
|
#
?
Mar 13, 2012 01:13
|
|
|
Factory Factory posted:Oh, I bet I know what the software FDE difference is that let me have good performance: fill the free space of the drive with a random-data junk file, then delete it to force a TRIM across the free space. That will re-sync the controller's idea of what's unallocated with the OS's. Not sure I understand how that would work. FDE by definition spans the entire volume. The entire thing is random data, junk data if you will if you dont have the key. The drive never sees empty space unless you are working with an unencrypted drive and just encrypting individual files. The controller always sees filled sectors, not 0's or unused space, but randomized data since it would otherwise give away "real" important information versus "junk" free space. A TRIM command would never pass, since the controller and software encryption are working on multiple levels. Those sectors would still have randomized data in them to prevent brute forcing real files versus blank space. EDIT: I wonder if BitLocker works a bit different. I don't think BitLocker encrypts all the free area and allows TRIM stuff to work. TrueCrypt though would really need 20% or so leftover on the SSD unused so GC can still cope. dietcokefiend fucked around with this message at 02:38 on Mar 13, 2012 |
|
#
?
Mar 13, 2012 02:33
|
|
|
I've been experiencing a lot of freezes lately with my 180 GB Force GT. It's not a BSOD, but the OS gradually gets less responsive until it completely locks up. It seems to happen whenever I do something that involves a lot of writing to the disk (downloading in uTorrent, running a VM, sometimes playing a game in Steam). I read up on the Corsair forums and there's a few other people experiencing issues but I can't seem to find a reliable fix. I tried the Intel RST drivers, tried some registry hacks, etc, etc but nothing's working. Some people mentioned that it's just a problem with the Sandforce controller and other drives experience the same issues. Is it possible a firmware update will fix this? I don't want to go back to my old, slow HDD but it looks like I might not have a choice for now.
|
|
#
?
Mar 13, 2012 02:56
|
|
|
Reith posted:I've been experiencing a lot of freezes lately with my 180 GB Force GT. It's not a BSOD, but the OS gradually gets less responsive until it completely locks up. It seems to happen whenever I do something that involves a lot of writing to the disk (downloading in uTorrent, running a VM, sometimes playing a game in Steam). You can backup and do a secure erase. Restore from backup, see if it works. SSDs should work exactly like normal HDs, if not RMA.
|
|
#
?
Mar 13, 2012 02:57
|
|
|
redeyes posted:You can backup and do a secure erase. Restore from backup, see if it works. SSDs should work exactly like normal HDs, if not RMA. I should probably note that I had it for ~2 months and as far as I can tell it worked fine up until a few days ago.
|
|
#
?
Mar 13, 2012 03:01
|
|
|
Reith posted:Yeah, I think I might just RMA at this point. Yeah probably a good bet. On the other hand, sometimes sandforce controllers can be recovered by secure erasing. I've seen in happen twice. I think it may have to do with failing flash but can't be sure.
|
|
#
?
Mar 13, 2012 03:03
|
|
|
Reith posted:I've been experiencing a lot of freezes lately with my 180 GB Force GT. It's not a BSOD, but the OS gradually gets less responsive until it completely locks up. It seems to happen whenever I do something that involves a lot of writing to the disk (downloading in uTorrent, running a VM, sometimes playing a game in Steam). What firmware is currently installed? If its not the newest you have pre-massive bug fix firmware. One that causes tons of blue screen issues.
|
|
#
?
Mar 13, 2012 03:50
|
|
|
dietcokefiend posted:What firmware is currently installed? If its not the newest you have pre-massive bug fix firmware. One that causes tons of blue screen issues.
|
|
#
?
Mar 13, 2012 03:59
|
|
|
redeyes posted:Yeah probably a good bet. On the other hand, sometimes sandforce controllers can be recovered by secure erasing. I've seen in happen twice. I think it may have to do with failing flash but can't be sure. I've had a failing drive fixed by a secure erase, personally. Basically, a significant portion of SSD failures stem from firmware issues; doing a secure erase is equivalent to a format & reinstall of your OS. Whatever bad state the firmware was struggling to deal with gets wiped clean and it starts working fine again.
|
|
#
?
Mar 13, 2012 05:37
|
|
|
I'm willing to give that a try (and probably should anyway before I resort to an RMA) but I have no idea how. What's the best way to make an image of the drive and then do a secure erase?
|
|
#
?
Mar 13, 2012 06:22
|
|
|
Just a note about the Intel Rapid Storage Technology: I installed the drivers on my system in preparation of getting a new SSD. Everything went fine... until I tried connecting an eSATA device. Everything looked fine at first, and the drive performed fine, but the event log soon got filled with error messages from the Intel storage driver about a failed parity check. (I am not using RAID.  )These messages are followed shortly by the computer completely freezing, with the fan running on high. I assumed this was a faulty drive, but some quick searching shows other people having a multitude of issues with the Intel drivers and eSATA devices. In short, if you use an eSATA drive and don't need hardware RAID, I recommend foregoing installing the RST drivers. You'll probably have all the features you need from the default AHCI controller.
|
|
#
?
Mar 13, 2012 13:02
|
|
|
dietcokefiend posted:EDIT: I wonder if BitLocker works a bit different. I don't think BitLocker encrypts all the free area and allows TRIM stuff to work. TrueCrypt though would really need 20% or so leftover on the SSD unused so GC can still cope. According to this post from the Building Windows 7 blog: Technet posted:Is Bitlocker’s encryption process optimized to work on SSDs? The way I'm understanding this, on a drive that supports TRIM there shouldn't be much difference between performance before and after enabling BitLocker.
|
|
#
?
Mar 13, 2012 13:27
|
|
|
Every one of our laptops we image that have SSDs are Bitlocker encrypted and have had zero issues with GC.
|
|
#
?
Mar 13, 2012 13:44
|
|
|
chizad posted:According to this post from the Building Windows 7 blog: Reading that I am really thinking that Bitlocker encrypts individual files on the fly and not the free space. Basically the volume is like any other NTFS volume, but instead of everything being a jumbled mess, it is orgranized encrypted files. That way the SSD still can manage free space versus file, whereas in the TrueCrypt FDE method it wouldn't.
|
|
#
?
Mar 13, 2012 15:09
|
|
|
dietcokefiend posted:Reading that I am really thinking that Bitlocker encrypts individual files on the fly and not the free space. Basically the volume is like any other NTFS volume, but instead of everything being a jumbled mess, it is orgranized encrypted files. That way the SSD still can manage free space versus file, whereas in the TrueCrypt FDE method it wouldn't. an SSD does not know what is a deleted file in NTFS or any filesystem; it's the operating system's job to tell it (this is why the OS needs TRIM support). With TrueCrypt FDE and an OS with TRIM support, you can achieve the same results as far as I know.
|
|
#
?
Mar 13, 2012 15:42
|
|
|
DNova posted:an SSD does not know what is a deleted file in NTFS or any filesystem; it's the operating system's job to tell it (this is why the OS needs TRIM support). With TrueCrypt FDE and an OS with TRIM support, you can achieve the same results as far as I know. With TrueCrypt though, if it doesn't maintain active randomized data structure across the entire disk surface, you could in theory start narrowing down what is real information versus no data. Plausible deniability and all that good stuff would go out the window with X amount of information sitting there. By definition there would never be TRIM commands since you would have a ton of unused space on the drive and someone could tell how much or how little information was present.
|
|
#
?
Mar 13, 2012 16:22
|
|
|
dietcokefiend posted:With TrueCrypt though, if it doesn't maintain active randomized data structure across the entire disk surface, you could in theory start narrowing down what is real information versus no data. Plausible deniability and all that good stuff would go out the window with X amount of information sitting there. By definition there would never be TRIM commands since you would have a ton of unused space on the drive and someone could tell how much or how little information was present. No, you can already do this with TrueCrypt. It's in their documentation. If an attacker has access to the volume over time it is definitely possible to narrow down what areas are changing files and what areas remain static. I really don't know how this meshes with TRIM though and the more I think about it the more I think it's not possible to work properly.
|
|
#
?
Mar 13, 2012 16:34
|
|
|
DNova posted:No, you can already do this with TrueCrypt. It's in their documentation. If an attacker has access to the volume over time it is definitely possible to narrow down what areas are changing files and what areas remain static. Well it wouldn't be ruling it out over time to see what stuff is real versus just free space. On a SSD a TRIM command puts the NAND back into a unused state. It would be clearly visible as a "nothing stored here, move on" deal. The only method that doesn't put any load constraint on a SSD at this point in time is hardware FDE built into the drive. I wonder if the next evolution might be 1MB or whatever of free space on the SSD for a TrueCrypt/etc bootloader and the rest handled through the controller's encryption. That way you can use longer stronger passwords and bypass consumer BIOS lovely 5-6 character limit that some have in place.
|
|
#
?
Mar 13, 2012 16:59
|
|
|
|
| # ? Apr 29, 2024 13:51 |
|
|
Got a question about a 32Gb thumb stick- it kinda belongs here being flash. Keep getting CRC errors writing to the drive about 1/2 the time. (TeraCopy compares source & destination CRCs) Any tools to check the disk for bad/expired flash sectors? I tried chkdsk with /r (locate bad sectors) and it didnt help
|
|
#
?
Mar 14, 2012 07:09
|
|
