My laptop, a Thinkpad T420, is pretty neat. I've had it for a year and figured it was time for an upgrade, one that I had been planning on for awhile.
Goal
SSDs have many benefits over traditional hard drives. I am most interested in having faster disk access and possibly lower power consumption, if I can get my platter-based hard drive to spin down if I don't need it. I want a hybrid setup, where the SSD is used mainly for the operating system, and the other hard drive for large, less-frequently-access files (music, large datasets for my research, backups, etc).
Keeping an eye to security, I want the speed of the SSD but still the security of my full-disk encryption setup, covered previously. So I will still be using LUKS. It's been harder to find much information on using multiple hard disks with LUKS and SSD encryption, so hopefully this post will help.
Also, when it comes to security, I want enough security/encryption to be careful, but not paranoid or terribly inconvenient (yes, yes, I know security and convenience is a tradeoff). If my laptop were ever lost or stolen, my mind would be at ease that its contents would not be recoverable to any casual (or even determined) third party. However, I realize that government-grade resources may circumvent my encryption, or I could be phished, fall prey to malware, or otherwise compromised.
Hardware
When it comes to hardware, the first priority is to not use an SSD with a SandForce controller. SandForce controllers play tricks with compression to get a higher write speed. Since only encrypted data will be written to the SSD, compression will have no effect and will just slow things down. So it's better to have a "dumb" controller that doesn't try to compress my data.
The Mushkin mSATA drives are highly rated, but they use SandForce controllers, so they're out. The Crucial m4 uses a Marvell controller without any compression. So, that's the one I ordered.
Here's the SSD, it's really tiny:
I opened up a back cover, note it's even smaller than the RAM:
And here is the SSD installed (I moved the WWAN leads to the side):
(Here's the Lenovo T420 Hardware Maintenance Manual for the official instructions.)
I booted it up, and saw that it was recognized:
$ journalctl -b | grep sdb
Aug 07 20:46:36 amonkira kernel: sd 2:0:0:0: [sdb] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
Aug 07 20:46:36 amonkira kernel: sd 2:0:0:0: [sdb] Write Protect is off
Aug 07 20:46:36 amonkira kernel: sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Aug 07 20:46:36 amonkira kernel: sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 07 20:46:36 amonkira kernel: sdb: unknown partition table
Aug 07 20:46:36 amonkira kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
It looks like it already has the latest firmware, 07MH (as found on the Crucial website):
$ journalctl -b | grep M4
Aug 07 20:46:36 amonkira kernel: ata3.00: ATA-9: M4-CT064M4SSD3, 07MH, max UDMA/100
Aug 07 20:46:36 amonkira kernel: scsi 2:0:0:0: Direct-Access ATA M4-CT064M4SSD3 07MH PQ: 0 ANSI: 5
So I won't bother with trying to update the firmware.
Now for some quick benchmarks, as suggested on the Arch wiki. Below, /dev/sda is the regular hard drive and /dev/sdb is the SSD. First, I use hdparm:
$ sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 10234 MB in 2.00 seconds = 5120.32 MB/sec
Timing buffered disk reads: 302 MB in 3.01 seconds = 100.23 MB/sec
$ sudo hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 10012 MB in 2.00 seconds = 5009.12 MB/sec
Timing buffered disk reads: 778 MB in 3.01 seconds = 258.87 MB/sec
The cached read for the SSD is pretty much the same, but the buffered read is 2.5x faster.
Now for gnome-disks (in the gnome-disk-utility package):
/dev/sda results:
Average Read Rate: 94.4 MB/s
Average Write Rate: 69.9 MB/s
Average Access Time 6.07 ms
/dev/sdb results:
Average Read Rate: 271.8 MB/s
Average Write Rate: 109.5 MB/s
Average Access Time 0.06 ms
Again, reading is about 2.5x faster. Writing is about 55% faster, and the access time is 100x faster!
Finally, using dd. This requires working within a filesystem, but none exist yet on the drive. So I set it up as a GPT drive and create a single partition:
$ sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.7
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
Creating new GPT entries.
Command (? for help): p
Disk /dev/sdb: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 525BD309-1EB5-4DEB-BD64-079173AEA9DF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 125045357 sectors (59.6 GiB)
Number Start (sector) End (sector) Size Code Name
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-125045390, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-125045390, default = 125045390) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Command (? for help): p
Disk /dev/sdb: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 525BD309-1EB5-4DEB-BD64-079173AEA9DF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 125045390 59.6 GiB 8300 Linux filesystem
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.
Then I create an EXT4 filesystem in the new partition:
$ sudo mkfs.ext4 /dev/sdb1
mke2fs 1.42.8 (20-Jun-2013)
Discarding device blocks: done
warning: 81 blocks unused.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3915216 inodes, 15630336 blocks
781515 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
477 block groups
32768 blocks per group, 32768 fragments per group
8208 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
And finally I mount it:
$ sudo mkdir /mnt/ssd
$ sudo mount /dev/sdb1 /mnt/ssd/
$ cd /mnt/ssd/
As far as partition alignment issues go, the partition was created starting at sector 2048, so we're fine. Now for the dd benchmark:
$ sudo dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 9.70329 s, 111 MB/s
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
3
$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 3.87424 s, 277 MB/s
$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.179846 s, 6.0 GB/s
When I run the final command 5 times and average the results, the mean buffer read time is 5.7 GB/s. The above benchmark showed that the write speed is 111 MB/s and the (unbuffered) read speed is 277 MB/s. The three benchmarks all agree with each other and are in the right range of other SSD drives tested by others.
A final note is that while the two SATA ports in the T420 are SATA III (6.0 Gb/s, or 600 MB/s), the mSATA port is limited to SATA II (3.0 Gb/s, or 300 MB/s) (reference). My (unbuffered) read speeds are approaching link capacity. It would be interesting to see my laptop's performance using a standard-sized SSD with the other SATA interfaces. Maybe someday I'll put one in.
Finally, I unmount the drive and wipe it using the ATA Secure Erase command, as outlined on the Arch wiki. One caveat was, during step one, that the status was reported as "frozen" until I suspended and then resumed, then it was "not frozen" and I could proceed.