[0] https://www.techradar.com/news/nand-and-cells-slc-qlc-tlc-an...
No, it doesn't halve the SSD lifetime. It is a little odd of you to make that claim.
First of all, you are assuming that 100% of SSDs die from being written, and die so quickly and so often from being written to that this is an enormous concern everybody using an SSD in a laptop should be worried about. In reality, a modern SSD you buy today might last you 10 years of normal use (including running Backblaze), but the rest of your computer simply won't last that long. Personally, I've never had one of my SSDs die. For any reason, including too many writes. Often I throw them in the trash perfectly working because I have upgraded their size for less money. Other times I get a whole new computer which comes with a whole new SSD. Backblaze runs SSDs in all of our "monitoring" computers that write the ever loving bejeebus out of their SSD drives 24 hours a day, 7 days a week FOR YEARS. I think we've had 1 SSD go bad after YEARS of writing at a rate 10x up to 100x higher than any home laptop user could achieve. And we're not sure it died due to too many writes.
So even if Backblaze doubled the writes (it doesn't, see below) it wouldn't have any measurable effect on your SSD's life. This is just provably false by watching servers that aren't running Backblaze write 10 or even 100 times as many times for 5 years as any consumer could ever achieve, and they still don't kill the SSD drives.
So, is Backblaze doubling the writes on your computer? Heck no. Backblaze only backs up valuable data files, not your operating system and certainly not your log files. The vast majority of writes to an SSD are not writing your one photo that you took today to disk - they are database transactions and log writes and system log write and system registry writes, etc. Backblaze puts in a lot of effort to exclude "chatty" log files (log files that are written all the time, all day long) because it saves our customer's network bandwidth and saves Backblaze space in our datacenter. So IN REALITY Backblaze's behavior is adding maybe a small single digit percentage of additional writes. The exact profile will matter what you use your computer for, but take email -> if you get 200 emails a day saved into an Outlook PST Inbox you might have 600 write transactions per day. But Backblaze won't back that up after every email, it would waste too much customer bandwidth. Backblaze might only back that up once per day. And only the part of the PST file that changed! So in reality, Backblaze only added 3 or 4 writes out of 600.
> especially since there’s no good reason for writing these chunks to disk
Different customers have different needs and different profiles, and Backblaze has to accommodate them. One reason a full snapshot is taken of the large files is that Backblaze wants a consistent "snapshot" of a file. On slow network connections it takes some customers 4 days to upload their Outlook PST file ONCE. Meanwhile they keep getting mail. If Backblaze didn't take a clean snapshot at one moment of time of this file, you'd get this corrupted file where the first 10 MBytes were from a file on Monday, and the last 10 MBytes were copied on Thursday from the same filename but totally different contents. Surely you see how that might be an issue?
And customers may or may not have the RAM required to hold a 10 GByte file in RAM, and none of them have enough RAM required to hold a 500 GByte file in RAM. Backblaze needs to store these "snapshots" someplace, so it stores them on disk.
Saying this is "for no reason" is disingenuous.
But at the same time, customers are very likely to have enough RAM to hold a 100 MB file, and definitely have enough for a 10 MB file in RAM. It might be better (faster, easier, less abusive to the drive) to store small files in RAM (for some well-chosen value of “small”, of course. Likely one that depends on the system RAM size and bandwidth.)
The Backblaze client code currently puts that dividing line at 100 MBytes. Any file less than 100 MBytes we call a "small file" and those don't get subdivided into 10 MByte chunks on disk, they get slurped up into RAM and just held there for the entire duration of being sent. For that code path, Backblaze can be configured to send up to 30 of these 100 MByte files in 30 separate threads which means (if the customer configures it this way) it can eat up 3 GBytes of RAM at peak. If you have that much RAM, it can really rip. If you don't, we recommend using fewer threads. :-)
The sub-division into 10 MByte chunks taking a one time "Snapshot" of the large file is for all files larger than 100 MBytes.