network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 1 month |
| seen | Apr 18 '12 at 1:37 | |
| stats | profile views | 1 |
|
Apr 13 |
comment |
Trim on encrypted SSD--Urandom first? @psusi Thanks. For performance and wear, what would be the best way to proceed with an encrypted system (so TRIM and wear leveling work)? Should I secure erase the SSD (e.g. wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing) and then set up the encrypted system, without first writing random data? Or I've seen some people suggest leaving some unpartitioned space on the SSD, which the controller can use for wear leveling. I'm not concerned so much about plausible deniability, gained through a drive first overwritten with all random data. I just don't want my files readable. |
|
Apr 12 |
awarded | Editor |
|
Apr 12 |
revised |
Trim on encrypted SSD--Urandom first? added 88 characters in body |
|
Apr 12 |
comment |
Trim on encrypted SSD--Urandom first? Please Note My question is not about the security implications of using Trim with an encrypted SSD. It's about how writing random data to the drive, before setting up an encrypted system, will effect the performance of the drive and the functioning of the Trim protocol (and whether zeroing out the drive would be better for the functioning of the SSD and Trim). |
|
Apr 12 |
awarded | Student |
|
Apr 12 |
asked | Trim on encrypted SSD--Urandom first? |
