SSD lifetime is typically defined by manufacturers by the number of p/e cycles (most S.M.A.R.T. values are calculated based on this metric). Doubling the number of writes will (roughly, modulo wear levelling and some other minutiae) double the number of p/e cycles. Ergo, twice the writes is equivalent to half the lifetime.
> 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
I only said concerns about excessive writes to SSDs are dismissed, which… seems to be what is happening right now?
> 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.
I’m not sure how this is an accurate comparison, since server-grade SSDs are not the same as consumer-grade SSDs—and even within the same market segment, higher MLC SSDs have orders of magnitude less write endurance. SLC SSDs are typically rated for 100k+ p/e cycles; QLC SSDs are rated at 1k cycles.
I can’t dispute that SSD endurance is excellent and manufacturers are often conservative on their endurance ratings, but as a software engineer, if I were working for a company whose sole purpose is to prevent data loss, I would absolutely be doing everything I could to avoid causing that data loss—things like avoiding excessive writes to disk.
> Often I throw them in the trash perfectly working because I have upgraded their size for less money.
Do you even recognise how privileged you are to be able to do this? Most people don’t have the luxury of buying and throwing away hundreds of dollars in computer hardware like this. Many people use their computers until they break, and I feel strongly that we as engineers owe it to others to not accelerate that process.
> 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.
Unless this has significantly improved in the past year, the Backblaze client writes logs to disk constantly. I’m pretty sure I raised a support ticket about this and it was ignored. Every update check writes a log entry to disk, every file that is backed up writes a log entry to disk, file checks write log entries, and on and on…
> One reason a full snapshot is taken of the large files is that Backblaze wants a consistent "snapshot" of a file.
I wasn’t talking about (or aware of) this behaviour, I was speaking only about the ~10MiB chunks that are created and written to disk during backups, which are all small enough to be kept in memory.
If those chunks are actually these “snapshots” of big files, I’m confused about that ensuring data consistency, since I didn’t have enough free disk space during evaluation to allow for the largest files to be duplicated, nor do I recall ever seeing hundreds of chunks sitting on disk at once (only one chunk per upload per process).
I also don’t know why, if you are concerned about data consistency, you’d be using file copies to create snapshots instead of something like VSS which is explicitly designed for this purpose.
When I evaluated Backblaze, the amount of data that the client wrote to disk was almost identical to the amount of data that was backed up. Maybe I should have qualified this specific follow-up by saying “in the pathological case”, but it feels like this is a hair-splitting discussion that distracts from the core message.