Running a Raspberry Pi 4 from a USB portable SSD

I've been experimenting with the Raspberry Pi 4 as both a low-cost Linux desktop computer and a server. As inexpensive as it may be, there's lots of potential in the hardware and plenty of ways to make the most out of the miniature computer. One way of doing this is to use a portable SSD instead of a microSD card.

Newer Raspberry Pi boards, starting from revision 1.2 of the Raspberry Pi 2 Model B+, have the ability to boot directly from a USB storage device such as a flash drive or portable SSD, eliminating the need to use a microSD card. The use of an SSD can greatly increase storage performance, capacity, and reliability over a microSD card (more on this below).

There are a number of considerations to doing this, some of which are specific to the Pi 4:

• The process is relatively simple. Raspberry Pi OS ships with an "SD Card Copier" utility, listed under Accessories in the main menu, which can be used to copy the running system to another storage device.
• This process will erase all data on the target drive, so be sure you've selected the correct drive and backed up any important data on it.
• The target drive must use an MBR partition table. If it uses GPT partitioning, the copy process will fail, and the drive will need to be repartitioned and reformatted with an MBR.
  
• After copying, the target drive will contain both a small boot partition and a large Linux ext4 partition containing the full root filesystem outside of /boot. If you'd prefer to have a smaller root partition, run resize2fs on the second partition of the target drive (usually /dev/sda2) to shrink the ext4 filesystem to the desired size, then use cfdisk on the whole disk (usually /dev/sda) to shrink the partition to that same size.
  
• It should be noted that there is no snapshot functionality involved, so copies are inconsistent and will not reflect the system state at any one point in time. As a result, I'd recommend rebooting the Pi and having no other applications running before beginning this process. Any services that are particularly sensitive to data consistency, such as database servers, should be stopped as well.
  
• Enabling this feature on earlier generations of the Raspberry Pi may require writing to a one-time programmable memory on the board, a permanent and irreversible process. On the Raspberry Pi 4 Model B, an EEPROM firmware update may be required to enable USB booting. For more details, see the official documentation.
• Some SSDs can require too much power for the USB ports on a Raspberry Pi. In particular, if the drive internally uses NVMe technology, such as an M.2 NVMe drive inside a USB enclosure or a retail portable SSD rated at more than 600 MB/s, it may require large bursts of power, which can cause the drive to disconnect while in use. SATA-based drives are less likely to experience this issue.
• I learned this the hard way while trying to use a Plugable USB-C to NVMe enclosure containing a 1TB Samsung SSD 970 EVO Plus. The system simply could not finish copying the operating system without the drive disconnecting during the copy. This issue did not occur with a 500GB Samsung SSD 850 EVO in a StarTech USB 3.1 Gen 2 enclosure.
  
• Trim, which is needed to maintain optimal performance on SSDs, will not work without some manual configuration, even if the drive otherwise supports it. Jeff Geerling has a detailed blog post on how to enable it; it's a rather complicated procedure and I won't be repeating it here.

Why use an SSD instead of a microSD card?

Raspberry Pi computers are designed primarily to use inexpensive SD or microSD memory cards for system storage. However, most microSD cards are not designed to be used as the boot drive or primary storage device for a computer. Instead, they are typically optimized for sequential or streaming I/O where data is read from or written to the card in large chunks. This makes sense given that these memory cards are primarily used to store pictures, videos, music, and other media files on devices like smartphones and cameras.

But computer operating systems rely much more on random I/O, where small bits and pieces of data are read and written in many different places on the storage media. A typical SD card, with a low-power controller tuned for optimal sequential I/O performance, will often perform poorly when asked to process many small random reads and writes. SSDs can deliver much higher performance than memory cards, especially in random I/O.

An SSD will also be much more durable than a memory card when used as an operating system drive. I won't go into detail here, but suffice it to say that due to differences in flash memory controllers, firmware features and optimizations, storage capacities, and the underlying NAND flash memories themselves, an SSD will be much less prone to failure than a microSD card over extended usage in a Raspberry Pi. They also provide valuable S.M.A.R.T. information which can be used to monitor usage statistics and possibly detect imminent failure, making it easier to avoid data loss. (On Raspberry Pi OS, you'll need to install the smartmontools package to use the smartctl command and read S.M.A.R.T. data.) Of course, any storage device can fail without warning, so it's always important to maintain current backups.

Using an SSD as a Linux swap device isn't (usually) as destructive as you thought it would be

It's been a while since I've posted something on this blog but there's something I'd really like to get out of my head.

I've read, and continue to read, claims from others on the Internet that putting swap space on an SSD is bad for it and will quickly kill it. However, these statements rest on the assumption that the swap space will be used heavily or that the SSD's endurance is low enough that this would cause it to fail well before the end of its designed service life. In the vast majority of situations, neither of these are true. Even on bottom-bin hardware like Bifrons (a cheap Lenovo netbook with 2 GB of memory and 64 GB of eMMC flash storage), where endurance is more likely to be an issue, it's still very likely that the flash memory will last the intended life of the system.

Several months back, I took an old 64 GB Plextor M5M mSATA SSD previously used in one of my old laptops, put it in a StarTech USB 3.1 Gen 2 enclosure, and plugged it into the USB 3.0 port on this laptop. I then secure-erased it, partitioned 8 GB of that drive as a swap partition, and enabled it as swap space. Using the Linux iostat command, I monitored the amount of data written to the drive over time as I used the system for everyday web browsing and productivity. The worst I saw was 170 GB of writes to the drive over just shy of nine days of usage, or about 20 GB of writes per day from swapping. Remember that this system has just 2 GB of memory so some swapping is likely to be unavoidable. It's also noteworthy that swappiness was set to 100, which makes the system swap more aggressively than normal (the default is 60).

20 GB per day is well within the endurance limits of most modern SSDs. A good name-brand SSD like the Samsung SSD 860 EVO will be rated for far more than that over its warranty period; the 250 GB version of the 860 EVO is warranted for five years or 150 TBW (total terabytes written). That's 84 GB per day over five years, and 20 GB is less than a quarter of this value. Even if you add another 10 GB per day (because a typical user would put the system/boot partition and the swap partition on the same disk), you're still not using even half of the drive's rated endurance within its warranty period. Even cheaper SATA SSDs with lower endurance ratings are unlikely to fail under this kind of workload.

This does not mean that swap is completely harmless, as endurance problems can still occur if you're swapping to a low-cost, low-capacity flash memory device. The eMMC flash module on Bifrons is rated by its manufacturer (SanDisk) for 44 TBW of endurance. This is 40 GB per day over three years, or 24 GB per day over five years, which should be enough to last the service life of the device. However, eMMC modules are permanently installed in the device and cannot be replaced without highly-specialized equipment (they are soldered onto the motherboard). Furthermore, the limited capacity of the device means that the typical consumer will use most of its capacity, which increases write amplification and reduces the effective endurance of the NAND, possibly below its specifications, and many netbooks of this kind have just 32 GB of storage which further compounds the endurance issue. (The same also applies to low-cost external flash memory devices like SD cards or USB flash drives.) This is, in fact, the reason I put the swap onto an external SSD and not on the system's onboard flash memory.

But this isn't the case for the vast majority of system configurations, where the benefits of placing swap on an SSD outweigh the risks. Most flash memory devices are far faster than any electromechanical hard drive; even if swapping significantly degrades system performance, the performance impact of swapping to an SSD is much lower than swapping to spinning rust. The above endurance issues only truly apply if 1) you're swapping to a cheap and small flash memory device like an eMMC chip or USB flash drive; and 2) your system has low memory and your usage patterns are such that you need to swap more than occasionally. Most systems have enough memory that swapping only happens rarely, if at all, rendering the whole endurance issue moot. And even when swapping is necessary, the drive isn't going to be written to so much that it'll exhaust the endurance of the drive and cause it to fail prematurely. Swapping isn't going to cause the drive to get hundreds of gigabytes or terabytes of writes per day. The 20 GB per day figure is the highest that one might encounter in a typical day of usage, and most users aren't going to see this much swapping.

If endurance is still a concern, there are solutions like zram which can effectively compress the contents of system memory and therefore allow more data to be stored in RAM before the system needs to swap to disk. While this comes at the cost of increased CPU usage, you'll still get better performance than if you're swapping to disk, and fitting more data into memory means that less data needs to be swapped out and written to the flash memory.

Ultimately, for the vast majority of use cases, putting swap on your SSD isn't going to kill it.

How to save energy on gaming: Experiments with lowering power target on the GeForce GTX 1080 Ti

Before I begin, I'd like to provide some relevant background information.

My bedroom has a tendency to trap heat, and is usually the warmest room in the house. It also faces west, which means that in the summer months, the room can get unbearably hot unless the central AC system is turned on full-blast, complicated by the fact that there is only one HVAC register in the room. With the Astaroth desktop's power draw often exceeding 400W under full gaming load, converting most of this energy into heat, keeping the room at a reasonable temperature during long gaming sessions can be challenging.

This led me to the question: How do I get the system to run cooler and use less energy without unacceptably degrading game performance? Read on for the answer...