If you ever tried Qubes OS on a conventional spinning hard drive, the first thing you would notice is your gray hairs would grow faster than it booted. It would take ages from startup until you could use the computer to do something meaningful. So I am quite confident to guess the majority of Qubes users are now using some forms of SSD instead.
Qubes, however, is an SSD killer, at least with its default configuration. One might argue that it is the price of security via compartmentisation. But I still think we can have both security and long-living SSD.
My journey with Qubes OS started few years ago when Qubes was at 4.0 beta and release-candidates. At that time, I wanted to study how Qubes worked, so I turned off LUKS and LVM and just used normal partitioning while installing Qubes. This way, I was able to access Qubes partition from Windows, saw the files and settings, and got the idea what Qubes OS was. But the price was in the course of just few months, the wear level of my brand new SSD jumped up to 36 with 6.5TB written to disk. It was a small SSD, of course. And the 6.5TB was the result of constant cloning-and-deleting of root, private, volatile images, among others.
Certainly I was not using Qubes default configuration. But still. Even now, using Qubes 4.1 in its default configuration (LUKS, LVM thin provisioning) I can still see between 5GB to 10GB of data written to the SSD daily (compared to 200MB to 300MB if using Windows, same usage pattern). Needless to say, if I need to download and keep something, I save it on an external HDD). If I had to update one or more templates, the amount of data written that day would be in the 15GB to 25GB range.
My worst experience with Qubes was when I restored a VM having 5GB data from backup, that operation alone resulted in 19GB, almost 4 times the amount of data, written to SSD.
In an ideal world, I could imagine Qubes to have a “magic switch”. In the “live” position, Qubes would write absolute nothing to the media it booted from (like Tails), and in the “maintenance” position updating or installing new software would be possible. Until then, I will have to try tweaking Qubes to minimise the amount of data it writes to the SSD during its operation. And that is the reason I started this topic: To collect all SSD wear related information into one place.
Some possibilities that I have thought of or tried with limited success:
Settings related to partition boundary, cluster size
Settings related to TRIM (discard) operations
Using minimal templates
Defragment ext4 partition, or re-format it with different settings to make it more compact
Using tmpfs whenever possible/make sense
This list is far from complete and I would appreciate to see more tips or links to relevant topic added. I do not forget the main strength of Qubes is security, so even more important than new tips and links, explanations why doing “this” or “that” is a good/bad idea would be the real treasure for me who is still on the learning curve how to get the most out of this fantastic OS.
For a start, I link this topic (How I learned to love Liteqube (and why you should, too, even if you have enough RAM) - #2 by unman) which I found very promising. Apart from having to install new packages in dom0 which Qubes officially advised against, has anyone any thought (pros and cons) about it?