etbe

It is thick for many reasons, having separate chips for security means a bigger motherboard, having a socket for a security chip, etc. But the battery is really big, much bigger than is common for modern phones.

The Librem5 is twice as thick as any other phone I have owned in the last 10 years. In general I agree that thicker and heavier phones would be good but in this case they seem to have already got to the upper limits of what's considered acceptable nowadays.

If you use the - option in syslogd configuration for non-synchronous writes then /var/log will be only a tiny portion of writes. If you have a mail server then the many log messages about a message delivery will have hardly any write load compared to all the synchronous writes to the mail queue and mail store.

The only time I've seen a significant part of write load coming from /var/log is when the systemd-journald log database or a database server replication log or rollback log is there.

I'm not sure it makes a lot of difference unless you have hundreds of snapshots. The way changes work to BTRFS is that every change without snapshots does most of the same stuff that a change with snapshots does. If however you have many snapshots (more than 500 according to rumours, I've seen it with over 1000) performance can get really bad. If your script to make snapshot backups works and the script to remove old ones doesn't work properly then the system runs fine for months and suddenly goes ridiculously slow.

A VM with a BTRFS filesystem running on a host using BTRFS gives serious write amplification. But if the real storage is SSD then it's not too bad.

In addition to cables and backplanes that have been mentioned, the entire path from RAM to PCIe to disk controller has non zero risks of errors. That said I'm pretty sure that the BTRFS errors I've seen from SSDs have all been the fault of the SSDs in question.

Also note that hard drives have had internal error detection and correction codes for decades, so SSDs doesn't change things much. Probably most checksum errors are misplaced writes and missing writes.

If you want to mix SSD and hard drives then you probably want bcache.

Most things last longer than their warranty, if even 5% of an item fail to reach the warranty then it's a disaster for the manufacturer. Planning for replacement is probably a good idea when you are 5* the warranty.

When I was using a Thinkpad X1 Carbon Gen6 with Linux it would hit a thermal limit and throttle the CPU speed if I read from NVMe at maximum speed for more than about 30 seconds. That was partly due to an issue with the way Linux and the BIOS interacted which gave a lower thermal limit than expected.

But it really depends on what NVMe devices you use, I've seen cheap ones bottleneck at 30MB/s when doing continuous writes with no downtime.

RAM is getting so cheap and easy to get that in recent years I only really use swap on laptops. Using a CPU core for compression isn't a big deal in a laptop because you usually have 4 cores and only 1 of them in use most of the time.

In the post I wrote 'between the 2 SSDs SMART reports 18 uncorrectable errors and “btrfs device stats” reports 55 errors on one of them'. That's 37 errors that BTRFS found that mdadm wouldn't have found. 37 errors out of 500G of data isn't a lot, but it depends where it occurs, if it's in the root directory then it will mess up your day (annoyingly BTRFS doesn't track where the errors were so you can't easily determine what the implications of not having BTRFS might be). That is not unusual, I have had similar things on almost all my systems that run BTRFS or ZFS.

Also I use snapshots too.

Sometimes that's a good idea, sometimes it might make things worse. A previous server that had a RAID-1 of SSDs was limited by SSD write speed. As the SSDs got old the write speed dropped significantly. If I had 2 servers that each had the same brand of SSDs then one server would need both SSDs replaced while if I had 2 servers with different brands then each server would need a single SSD replaced which would have been more hassle.

zram is a good thing. However in my investigations in 2014 "my conclusion was that swap wouldn’t be a problem as no normally operating systems that I run had swap using any significant fraction of total disk writes". During the last 8 years the amount of RAM in all my systems has increased significantly so swap is even less of an issue.

The "server which runs my blog (among many other things)" probably has most of it's writes from a mail server for dozens of domains and has some commercial web sites that are very interactive and database backed.