Solid State

We have been shopping here at the Dragon Propulsion Laboratory. A pronounced drop in the prices of Samsung SSD drives featured on Amazon.com quite simply forced our wallet hand (or was that our browser's autocomplete?) into an impulse purchase. Following in the footsteps of "Chaos Manor," the recurring hardware exploration column in Byte Magazine that so many used to look forward to every month, I comprehensively kick the tires of a new storage device. In memory of Jerry Pournelle [1], Chaos Manor's unequalled author, I will try my best to have some fun while doing so.

Parking Electrons

The drive in question is a solid-state 64-layer V-NAND device manufactured by Samsung. The Samsung T5 is an external drive, quite a bit smaller than older external drive formats defined by the dimensions of their internal 2.5-inch SATA devices, coming in at a mere 2.3x3x0.5 inches (5.8x7.6x1.3 cm) – smaller than a Post-it note (Figure 1). Available in sizes ranging from 256GB to 2TB, the specimen in our lab is the MU-PA500B 500GB unit [2], priced around $123 at the time of writing. As a second-generation USB 3.1 device, the interconnect maxes out at 10Gbps, making external drive benchmarking a problem of the past where USB C ports are available.

Figure 1: Samsung Portable SSD T5, 500GB, with a Post-it note block and USB key for scale.

First Look

Desktop Linux distributions will automount this large device with no trouble whatsoever; it ships formatted as a single exFAT partition. The specified maximum transfer rate is 540MBps. Does the device keep up with this expectation? Very much so (Figure 2). The simple benchmark built into the Gnome Disks tool yields a remarkably close 541.6MBps average read rate, with a stunning 0.09ms average latency (tested with 1,000 samples of 10MiB). The large amount of data written highlighted the drop in write performance occurring when the SSD garbage collection mechanism kicked in. Because NAND memory with existing data in its cells must be erased before new data can be written in, rapidly writing gigabytes of data, as the benchmark is doing, allows you to observe the lower (yet still quite impressive) write performance the drive will provide under a high write load.

Figure 2: Gnome Disks benchmark (1,000 10MiB samples) running on the Samsung T5. Note the garbage collection slowdown.

Shell Exploration

At this point, I'll take this opportunity to showcase a few standard disk management tools. Gnome Disks already revealed the disk to be sdb mounted on the path /media/federico/Samsung_T5, but I could just as easily find out from the shell (Listing 1) where sdb is actually mounted:

federico@cybertron:~$ lsblk | grep sd
sda      8:0    0 119.2G  0 disk
|--sda1   8:1    0   500M  0 part /boot/efi
|--sda2   8:2    0   128M  0 part
|--sda3   8:3    0  78.6G  0 part
|--sda4   8:4    0   990M  0 part
|--sda5   8:5    0  37.3G  0 part /
 **--sda6   8:6    0   1.8G  0 part [SWAP]
sdb      8:16   0 465.8G  0 disk
 **--sdb1   8:17   0 465.8G  0 part /media/federico/Samsung_T5

federico@cybertron:~$ lsscsi
[2:0:0:0]    disk    ATA      SK hynix SC311 S 0P10  /dev/sda
[3:0:0:0]    disk    Samsung  Portable SSD T5  0     /dev/sdb

And, voilà, there it is. On this Ubuntu Bionic (18.04) desktop system, the volume was automounted. On a server system like Ubuntu Server 16.04, you would have to mount the volume manually instead, like so,

federico@ferenginar:~$ mount /dev/sdf1 /mnt/external
FUSE exfat 1.2.3

which in Xenial requires exfat-fuse and exfat-utils to be installed. mount(8) is a complex command [3], but I want to share another pointer before returning to performance: /etc/fstab [4] controls the static mounting of filesystems at boot time; it is a key resource on systems that are not set to automount. A comprehensive mount tutorial with many excellent examples can be found online [5], and fdisk(8) [6] has more details to contribute (Listing 2).

federico@cybertron:~/Desktop$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0xa3f36884
 **
Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976770112 976768065 465.8G  7 HPFS/NTFS/exFAT

The sector size information could be most useful if I were re-partitioning the drive, because partitions need to align to the correct byte boundary to deliver full drive performance [7].