Optimise your install
Speed up access to your RAID array using bcache, then boost your gaming and mining performance with better graphics drivers.
The discrepancy between SSD and hard disk speeds can become tiresome. One day, solid-state storage will offer the capacities of today’s hard drives at sub-astronomical prices, but for now we’ll just have to compromise. Gamers have long established the tradition of having a small Steam library on their SSDs to speed up load times for favoured titles, but with major releases regularly weighing on the wrong side of 50GB, this entails frequent shuffling in and out. And in our experience anyway, Steam makes moving games between libraries a haphazard process, often ending with the whole thing being needlessly redownloaded. And that makes us sad.
But all is not lost. If you have some free space on your SSD then it can be used to cache data from other, slower devices. This isn’t going to magically boost HD speeds for every type of operation, but with some tuning certain types of I/O can see a tremendous benefit.
Unsurprisingly, there are a few gotchas before we can make use of this free speed. Chief among which is that – unless you want to make things really complicated – the drive/partition that you want to speed up will need to be formatted. Just as well we haven’t put anything on the RAID array we made on the previous page.
So first we have to wipe all traces of anything resembling a filesystem from the RAID drives (bcache is most fussy about this). Please make sure the devices are correct here, otherwise you could end up having to do an unscheduled reinstall, lose valuable data, or other bad things:
$ sudo wipefs -a /dev/sdb $ sudo wipefs -a /dev/sdc
The first step is to install the required tools:
$ sudo apt-install bcache-tools
Next we need to create a backing device. The nomenclature is perhaps a little backwards here, because this refers to device that we want to cache (our RAID array). The (typically faster) device that houses the cache is known as the cache device. Prepare the first drive with:
$ sudo make-bcache -B /dev/sdb and repeat for the second. This will create nodes for the backing devices (/ dev/bcache*) which we’ll use instead of the traditional /dev/sdb etc.
Now we need to create our cache device. Remember that suspicious logical volume we made at the beginning of the tutorial? Now is its time to shine. This works for regular partitions or whole devices too:
$ sudo make-bcache --block 4k -C /dev/mapper/mint--vgbcache
The --block argument should correspond to the block size of the backing device (this is almost always 4k nowadays). It’s possible to specify a --bucket argument as well, which should correspond to the caching device’s erase block size. This is often hard to discover, so don’t worry too much about it, the default is probably fine.
We can recreate our RAID using the new backing devices:
$ sudo mkfs.btrfs -d raid1 /dev/bcache0 /dev/bcache1
Find their UUIDs with blkid and change the appropriate line in /etc/fstab. Before bcache can work its magic, we need to pair the backing devices with our cache, and to do that we need the latter’s cache set UUID, which you can find with the following:
$ sudo bcache-super-show /dev/mapper/mint--vg-bcache | grep cset.uuid
Substitute this magic number for cset.uuid to attach the first drive to the cache, and repeat for the second (bcache1).
“Unsurprisingly, there are a few gotchas before we can make use of this free speed”
The second command should return clean confirming that the cache is activated and healthy:
$ echo cset.uuid | sudo tee /sys/block/bcache0/bcache/attach $ sudo cat /sys/block/bcache0/bcache/state
This will persist across reboots, so no need to worry about it ever again. Bcache offers three caching modes: writethrough (the default), writeback or writearound. Writethrough and writearound only cache reads, the latter bypassing writes from the cache entirely, whereas writeback caches both reads and writes. This can be changed with, for example:
$ echo writearound | sudo tee /sys/block/bcache0/bcache/ cache_mode
Graphics drivers
AMD deserve some praise for their change in driver tack. Gone is the old, proprietary fglrx driver – older cards are supported by the FOSS radeon driver and newer ones by amdgpu , while middle aged (Southern and Sea Islands) ones are in fact supported by both. AMD has contributed an awful lot of code to these (it’s just open sourced its Vulkan driver and a huge amount more is coming in Kernel 4.15) with the upshot being that you’ll very likely get reasonable gaming performance out of the box. A proprietary component is available, which you can read about below, but this is aimed more at compute workloads than gaming.
The Nvidia situation isn’t so rosy. The free nouveau driver has never been in better shape, but Nvidia has contributed very little to it. It got to where it is by clean room reverse engineering. Acceleration on newer cards requires signed firmware blobs, which aren’t redistributable, and even on older (Kepler) cards reclocking has to be done manually to get reasonable performance. However, Nvidia’s proprietary driver tends to work well and, combined with a fast card, is almost certainly the best choice for AAA gaming on Linux.
The newest version of Nvidia’s proprietary driver can be download from its website, but it’s considered more prudent to install it through your package manager. It won’t be the latest bleeding-edge version, but it won’t have the latest bleeding-edge bugs. There’s a long and illustrious history of people downloading the driver from the website and rebooting to the blank screen of hopelessness. Mint makes the driver installation process easy: just open the menu and choose Administration>Driver Manager. Your card should be detected and you should be able to choose the Nvidia driver.
If you want a newer version but don’t like the idea of polluting your filesystem with things installed without Apt’s purview, then consider the graphics-drivers PPA. Go to Administration>Software Sources>PPAs and select “Add a new PPA”. Type ppa:graphics-drivers/ppa into the box and update everything. Return to the driver manager and you should see some newer versions of the Nvidia driver. These should be considered experimental but are less likely to break your system than doing what Nvidia’s website tells you to.
Even if you want to stay with open source drivers (whether you have an AMD, Nvidia or integrated Intel GPU), there may be some benefit to updating other parts of the display stack. This is especially true for distributions based on Ubuntu 16.04. There are a number of PPAs that will help you do this: padoka and oibaf which provide an entire X and Mesa stack (Padoka offers a stable and an unstable version). We suggest reading more about these before using them. There’s also the semi-official Ubuntu-X PPA, which offers stable upstream releases of X components. This is probably the best place to start – add it as above from Software Sources using the address ppa:ubuntu-x-swat/updates .