Question Current state of using compression on SSD's

[CakeMonster]

I've been helping building PC's lately, and I often see people with too small SSD's, at least when you take their 1 or 2 most played games into account. So that got me thinking back to Sandforce if anyone remembers (10 years ago or so). Those disks natively compressed content before storing it and one byproduct was that in some cases it actually improved performance because data could be written and read faster when compressed. But most importantly IIRC you avoided the performance penalty of a nearly full SSD because it wouldn't be as full as non-compressed SSD's.

So, now many years later when SSD's are the standard, but they are still too small for many gamers, and there's also the upcoming next gen consoles with space for way too few games, how does compression fare today? IIRC at least one of them do actually introduce compression? And CPU's must no doubt be more able to handle any overhead from it now?

So to boil it down to some points that I wonder if can be clarified:

1) Do any SSD controllers compress data today? If not, why not?

2) Would enabling compression be advised for someone struggling with a small SSD today? How does Windows handle it now?

3) Any technical experiences/guesses about CPU utilization, read/write speeds, type of data benefiting, downsides compared to the Sandforce days, etc?

 

[razel]

1) I would imagine that it is a side benefit from encryption algorthim if used
2) Not advised. With SSDs commonly reaching $75 for 1TB during the holidays, just buy a larger one
3) That's why it's not advised

 

[damian101]

1) There are SSD controllers who compress data, but just to achieve higher write and read speeds for easily compressible data. But they won't save you any storage capacity. I don't think it's possible for SATA/SAS and Nvme storage devices to compress data on their own. These drives only provide sectors to the operating system. If the operating system writes to a sector and due to compression it doesn't actually fill that sector it will move to the next free sector anyway as the drive can't tell the operating system how full the sector is. The drive could of course provide the operating system with a completely virtual sectors, but the drive would need to show a bigger drive than its actual size to make use of compression, which isn't possible as you can't predict how well the data will compress. There might also be data integrity issues.
Filesystem compression has the potential to be much faster than any theoretical SSD hardware compression by an SSD anyway. Unless you would put a powerful, actively cooled processor on the SSD that can compete with a CPU.
But as I said, I don't think hardware storage compression is possible with current storage protocols anyway. And I don't see it becoming a thing anytime soon, if ever.

2) Under Windows I always enable NTFS file system compression on SSDs. It saves space and actually makes many workloads faster by increasing the practical read speed of the drive, and also works very well on the C: drive. On HDDs it leads to much faster fragmentation which is why I wouldn't recommend using it on them.
Under Linux I normally use the Btrfs file system for everything and always have zstd compression enabled, even on HDDs.

3) I once did some speed tests with compression enabled on the C: drive. Benchmarks showed basically no difference for read speed and worse results for write speeds, but that's because every decent disk benchmark program writes random data, which is pretty much not compressible. Programs and game levels generally loaded a bit faster, even Windows even booted a little faster. CPU utilization wasn't an issue, but it was also a powerful desktop CPU. On weaker CPUs or faster SSDs you might see high CPU load during heavy write operations. Read operations shouldn't produce much load on modern CPUs. I have NTFS compression enabled on the SSDs of all my Windows laptops.

 

[CakeMonster]

Thanks, those clarifications were useful.

So you mean that those SSD controllers who compress data does it in a way that writes and reads less to improve performance, but there is no actual extra space for the user? That makes sense. Because it has to write and read less to the actual disk in order to gain that performance, right? If that is the case, I wonder why its not more used if it will gain some % extra at least in some benchmarks (and help longevity). Is that because the controller would need to do more work and produce more heat?

Yeah, as for file system and Windows you pretty much confirmed my suspicion, considering it was almost 10 years ago I read that there wasn't much of a CPU penalty (and a read/write speed gain), it would make sense that its even better now. I guess enabling it for windows and app would be a no brainer? Are there red flags with some kind of edge cases?