[SOLVED] Partitioning an SSD - should I leave unallocated space?

[br1anstorm]

Like most users (I guess) I'm gradually shifting from old-style spinning hard disk drives (HDD) to solid state drives (SSD) - initially for external storage, but where feasible (eg laptops) by replacing internal drives.

As I don't have the latest cutting-edge systems, and because I prefer the devil-I-know, I still use MBR/legacy partitioning.

I recently came across some advice in another forum which said - in connection with the wiping and re-partitioning of an SSD - "Wipe it thoroughly, then create/format a partition on it of no more than ~80% (leave the rest for overprovisioning)."

I wonder if anyone can clarify and explain what lies behind this? What exactly is "overprovisioning". As I read it, the suggestion is that up to 20% of an SSD should be left unallocated. Should it be formatted (but left as free space?), or genuinely "unallocated" (ie space not formatted or partitioned)?

Or is the advice misleading: was the message intended to be that an SSD or the partitions on it should not be filled absolutely full, but only to about 80% of the notional maximum capacity? A bit like HDDs, which tend to slow down once they are nearly-full (especially if fragmentation means that bits of files need to be searched-for....)

[dorsetUK]

https://easylinuxtipsproject.blogspot.com/p/ssd.html

[br1anstorm]

Ah - I should have thought of checking Pjotr's site before asking the questions! The answers are indeed there.

[rene]

Explicit overprovisioning is not needed these days. What it is...

An important difference between HDD and SSD is that while on former any sector can be written to at any given time, on an SSD a "sector" needs to first be erased before new data can be written to it. Quotes around "sector" since erase granularity on an SSD, an erase block, is in fact much coarser than 1 sector but for now never mind.

Should as on HDD modulo defect management some given sector N always be located at the same physical on-platter/flash location, any write would need to wait for the slow erase to complete first; as such the sector map on an SSD is a software construct alone: when software writes to not currently erased sector N the SSD-firmware simply writes to some already erased sector instead and then only maps that newly written sector in as sector N while marking invalid the old sector N and scheduling it to be erased in the background as time permits.

In fact... the slow erase process isn't the only or even major reason for this sketched decoupling of physical and logical sectors: flash can endure only a finite number of these erase/program cycles and the SSD-firmware wants to as such spread out writes as evenly as possible over all sectors so that not e.g. sectors at the start of the disk wear out earlier than those at the end: a process called wear-leveling.

In any case to be able to do the above the SSD clearly needs a reservoir of free/already erased sectors on hand and this is what overprovisioning is (better, was once) about; having a reservoir of free sectors through unpartitioned space; a set of sectors that never gets written to from software and could be used in that above sketched manner.

However. Actual explicit overprovisioning is already a thing from the past. First of all since a modern SSD has ample internal overprovisioning, second due to support for e.g. TRIM and even more to the point these days, intelligent garbage-collection. You should not fill up a filesystem for more than say 80% anyway lest you'd get fragmentation issues on that level and what with due to those techniques the remaining 20% every bit as good to the SSD as free blocks as unpartitioned space would be, explicit overprovisioning is not needed anymore.

Finally need to quickly come back to that "erase block" remark from the start: whereas it wasn't needed to sketch the idea of things, erase granularity being in fact much larger than a single sector (on the order of several megabytes) means that the problem of needing to erase a sector before it can be written to is actually much more severe: with a static sector map not only would more sectors need to be erased, but data in the other sectors of that same erase block would need to be backed up and written back; definitely won't do. Even with a dynamic sector map as we have this issue still leads to an effect called "write amplification" where the same basically still needs to happen even if now in the background...

... but that's all not really important for the question. What is is that ample internal overprovisioning on modern SSDs plus modern techniques such as TRIM and effective garbage-collection means you can ignore all those Ghosts from SSDs Past and just use them as you would ever have done an HDD: they'll only last longer.

[br1anstorm]

Thanks rene - a very comprehensive explanation!

I take one very simple conclusion from all that. I can go ahead and set up partitions on the whole of an SSD, and I don't need to leave 20% (or indeed any of it) unallocated, because these days SSDs in effect have overprovisioning built in, and they have both TRIM and 'intelligent garbage collection' to manage the allocation and storage of data.

But I perhaps need to ensure I don't fill the disk with data up to the absolute maximum; because if I do so the disk will struggle to save and read it....

So, on we go. I think I can mark this as a question answered - or solved!

[rene]

I can go ahead and set up partitions on the whole of an SSD, and I don't need to leave 20% (or indeed any of it) unallocated [ ... ]

Yap. That's the tl;dr.

[Lady Fitzgerald]

https://easylinuxtipsproject.blogspot.com/p/ssd.html

Specifically, section 13.