Percentage Used: 1%
Data Units Read: 74,899,871 [38.3 TB]
Data Units Written: 71,233,417 [36.4 TB] Percentage Used: 1%
Data Units Read: 74,899,871 [38.3 TB]
Data Units Written: 71,233,417 [36.4 TB]These are wearing your SSD down.
And no, they will not be combined together because most of these shitty apps have O_DIRECT flag set or call fsync() after each write(), making the OS obligated to hit SSD with 4kb write.
SSD's don't operate that way, though, a 4kb write is guaranteed to become a bigger write since SSD cell/block is usually either 512kb, or 1mb, or 2mb, or hell even 4mb. So one 4kb per second becomes 4mb per second, and that's 345.6GB/day.
Pretty scary how one shitty app can ruin your ssd so fast, huh? I saw google drive app do 50 small writes per second. That's ~2TB/day.
echo "write through" > /sys/block/sda/queue/write_cache
This lies to the OS and tells it that drive writes don't need to be fsync'd. Replace "sda" with whatever your drive in question is, naturally. Note that this is not persistent, you'll need to configure your init system to do this on boot. You can verify it's working by looking at /sys/block/sda/stat (see https://www.kernel.org/doc/html/latest/block/stat.html).Next, in /etc/fstab configure your filesystem to be mounted with "barrier=0" (note that only some filesystems support this), which will often prevent data from getting written out to the disk at all, instead getting kept in cache.
You still need the first part because the filesystem layer won't cover all possible cases--for instance, LVM thin provisioning will issue a manual flush below the filesystem layer once per second, and there's no way to remove that.
One problem I haven't managed to solve is detection--in the unlikely event things don't shut down properly (e.g. a kernel panic), how do I find this out so that I can restore from a backup (rather than having something subtely corrupted somewhere)? This is conceptually easy with some global bit in a special sector used as a mutex, but I don't know of any existing off-the-shelf solution implementing this.
Also, if writes continue at the same rate then wear will increase exponentially, as the same number of writes are distributed over an increasingly smaller amount of space.