Hacker News new | ask | show | jobs
by lintfordpickle 657 days ago
I don't think the problem is necessarily space, but rather write-limits being used by superfluous logging
2 comments

That's where the wear levelling comes in, still expose 8GB of space to the host device, but internally have I dunno, twice that in cell capacity that you can move bits to as other cells wear out.

Its a shame mobile devices don't have a SMART equivalent, would be nice to have some warning as something approaches the end of its life.

Why do you want to spend money on hardware to solve a software problem? The software doesn't have to write the logs to the SD card.
Do you even have to limit the exposed space?

It’s not going to write at twice the rate just because more space is available.

You do, most SSD controllers already implement this. Have you ever wondered why most SSD's come in slightly odd sizes like 100GB instead of 128GB? The extra space is put aside and used for wear levelling and other maintenance tasks.

You can find out a bit more here https://www.seagate.com/gb/en/blog/ssd-over-provisioning-and...

I also remember a guide a while ago on how to reprogram a SSD to operate in SLC mode instead of MLC. You lost disk capacity but gained a large performance boost and a reduced error rate.

If I remember correctly it's also about eMMC having a much shorter life than UFS or similar storage. Though yes, unnecessary logging isn't helpful either. (Quick post-googling edit: apparently both use NAND, it's more about wear leveling apparently that makes the differences.)