So poison the oceans, suffocate the atmosphere, irradiate the land because in a few decades I won't be around anyway.
Selfish religious assholes !

But you are equipped to put forward your prescient feeling of a mini ice age coming really really soon as something all of us should plan for ?

I wonder if it is possible to start a class action lawsuit ?

Yes the dreaded ST3000DM001-1CH166. Terrible that one. We've had 17 out of 24 fail in a consumer NAS fail in less than 3 years. It's also a very widely deployed external drive since it's cheaper than WD and WD has its own external drive products.

0 failures on the spinning disk, but I will give it a few years.

You haven't used any recent Seagates then :D. When I look to my right I see two spinners being recovered with ddrescue :(.
And it's been like that for the last 2 years. These large spinning consumer drives are just crap.

Have you tried different brands ?

As I posted above, SMART 177 isn't a percentage, it's a P/E count. Documentation claims 2000 P/E cycles, independent testing shows close to 6,000. It's far less than even 1% used.

You're absolutely right. I wonder what other SMART values will be really important to SSD's.
Where is blackblaze's SSD data. My guess is it will be even more vendor specific as it is now.

Well no.. You're at 8 write cycles used, and 99%.

Right that value represent the raw maximum erase cycles (~3.000 cycles TLC, ~10.000 MLC, ...)
Let me quote wikipedia:

173 0xAD SSD Wear Leveling Count Counts the maximum worst erase count on any block.

Now my own raid0 drives:

Device Model: Samsung SSD 840 EVO 750GB
Firmware Version: EXT0DB6Q
User Capacity: 750,156,374,016 bytes [750 GB]

9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 5954
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 6
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 11617995820

Device Model: Samsung SSD 840 EVO 750GB
Firmware Version: EXT0DB6Q
User Capacity: 750,156,374,016 bytes [750 GB]

9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4510
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 4
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 8497497858

To be fair you've written ~950 GB and used 8%. If we simply extrapolate that you'll get ~12 TB or about 100 full drive writes.
Personally I'm also dissapointed in the consistency of the TLC NAND drives.
I get performance degradations on all my Samsung drives even though I've applied all the performance fixes.
I can't fathom though why you are putting the smallest (slowest) and cheapest drives in your server.
A Professional SSD (Sandisk or Intel) would be a lot more appropriate.

Mmm good thinking but you're assuming the swap partition is on the same drive as the system.
While this is assumption is right most of the time, so is it that the system partitions (/, /usr, ...), from which you'll be fetching that "new memory hungry application", also lie at the start of the drive.

I don't think that there's any evidence that the linux swapfile performs better - and in any case why would it being unfragmented be an advantage? Memory access is random, and so swapfile access is random, and so why does having it non-contiguous cause an issue?

That's exactly why you want a swap partition at the start of the drive where seek time is as low as possible.
You don't want a bad situation (swapping) to become even worse (swapping and seeking all around the drive).

Apparently It could have been Andrew Morton (https://lkml.org/lkml/2004/4/28/263).

Fucknose why anyone would actually want that though.

I believe it was Alan Cox that uses a high swappiness (99) to keep interactive programs always fed with real memory.
The idea is that the programs with low cputime (deamons, ...) gets paged out before the interactive programs.

That's not true, they are not eliminated. There is plenty of crappy kernel mode software out there (drivers, filesystem filters).
And the following (mostly hardware) problems also often cause BSOD's:
- Overheating GPU's.
- Broken stick of RAM, often due to dusty working environment, overheating
or abuse.
- Bad Hard drive causing corrupt system files.
- ACPI Power issues (hibernate,suspend,...).

Now most of these problems do crash all systems.
But personally I find the kernel panic and short stack trace on the console a lot more helpful
than the BSOD (not counting the MEMORY.DMP or Minidump files since these need windbg).

Actually it's not paper but rope.