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.
The T420 includes an mSATA port. As the name implies, it's meant for really small hard drives. I bought a 64 GB (60 GiB) mSATA SSD. This post covers the why and how I added it to my laptop.
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.
Software
Because this post is long enough, I'll split it here. I've decided to completely re-format my drives so I can start from scratch. I will use a dual-boot setup with Windows 7 and Arch Linux. I'll keep Windows 7 on the hard drive (I rarely use it, so why devote valuable SSD space to Windows?). I'll use LVM on LUKS for Arch with data split between both drives, fully encrypted.
Comments !