Question Does over-provisioning accomplish anything useful for typical SSD use?

[brocks]

I just got a Crucial MX500 SSD, and the software that comes with it recommends reserving at least 50GB for "over-provisioning," to provide space for load leveling.

But when I was trying to find out more about it, I found this post from a Micron employee, talking specifically about Crucial SSDs:
https://community.spiceworks.com/topic/451275-ssd-partitioning-is-reserve-space-necessary

"A key point is that, for most SSDs, and probably all of them from the big manufacturers, ANY UNUSED SPACE is used to manage garbage collection and wear leveling. It doesn't matter if it's unpartitioned space or if is is simply unused within the partition."

That makes it sound like I'll get the benefits of wear leveling without specifically setting up an over-provisioning region, and of course I'd like to have the extra 50 GB if it doesn't shorten the life of the drive. Plus, I keep reading that SSD's now are good for at least 10 years under normal use (I'm using it as my Win10 boot drive), even without heroic measures to extend their lives. And finally, I've also read that all SSD's come from the factory with about 7% reserved space for wear leveling, and that remains reserved no matter what the end user does.

So, should I go ahead and use the whole drive?

 

[hojnikb]

yes, thats exactly right. all flash devices can use free trimmed space for wear levelling and garbage collection, no need for extra partitions (its really stupid to do so).

just use it as you would any other drive.

 

[Billy Tallis]

all flash devices can use free trimmed space for wear levelling and garbage collection, no need for extra partitions (its really stupid to do so).

Unused space is available for GC/wear leveling use, but TRIMmed space is not necessarily reclaimed by the drive, because TRIM commands are ultimately just hints to the drive. If a drive's busy, it's free to ignore TRIM commands and carry on with regular IO. Some drives do guarantee that TRIM commands will not be dropped, by advertising a feature called Deterministic Zero After Trim, but that's mostly just enterprise drives. Good consumer drives probably behave the same way but just don't make it an absolute guarantee. SandForce drives in particular weren't very good at turning TRIM commands into actual reclaimed performance. largely due to their heavy reliance on compression to achieve good performance, exacerbated by their DRAMless architecture. Modern drives that perform transparent compression don't do it for performance reasons but for the sake of endurance.

 

[coercitiv]

So, should I go ahead and use the whole drive?

The one advantage left with over-provisioning is the drive will always have space to keep both write amplification and write performance to acceptable levels, even when the user fills all seen capacity. In other words it's great for systems where users have minimal knowledge about how computers work.

In your case though you shouldn't bother, or at least not with a big chunk of 50GB. Either use the entire drive and respect the simple rule of not filling the drive entirely unless for some temporary storage need, or alternatively setup a small reserve of 10GB or so.

 

[Insert_Nickname]

What the other posters say.

With a few caveats (mostly related to enterprise) over-provisioning is essentially a legacy concept today. It was relevant to older SSDs, but modern controllers are smart enough to work very well without. So there is no reason not to use the full capacity.

 

[TheELF]

And finally, I've also read that all SSD's come from the factory with about 7% reserved space for wear leveling, and that remains reserved no matter what the end user does.

That's not true some SSD drives give you access to all the space and you have to make sure not to use all of it.
For example both these drives are 128Gb but one only gives you 120Gb and the rest is overprovisioned while the other gives you all 128Gb
https://www.newegg.com/Product/Product.aspx?Item=N82E16820242399
https://www.newegg.com/Product/Product.aspx?Item=N82E16820301368

 

[Billy Tallis]

That's not true some SSD drives give you access to all the space and you have to make sure not to use all of it.

All SSDs have significantly higher raw NAND capacity than their user-accessible capacity. A "128GB" drive has a usable capacity of 128,035,676,160 bytes. 128GiB is 137,438,953,472 bytes, so you're getting access to at most 93.16% of the raw capacity of the drive. But NAND flash chips are never exactly 128Gb; they have spare area built-in to the chip to allow for defective blocks, and extra space to store error correction data.

For Intel/Micron 32-layer 3D NAND, each 16kB page (16384 bytes) was accompanied by an extra 2208 bytes for ECC info, and the die had 2192 blocks instead of 2048. So the TLC part that was nominally 384Gb (48GB) had a raw capacity of 62,597,627,904 bytes, compared to the expected 51,539,607,552: an extra 21.4% that's never directly usable on any SSD, and usually not counted when talking about overprovisioning ratios.

 

[R81Z3N1]

I am curious if anyone can provide some input how an older sata ssd works under DMLuks, cryptsetup which does not have trim support set by default.

For example, I have a cheap ADATA SP600 MLC 120 gb drive running under Fedora using Luks as the crypt container. It was setup to use whole drive no extra provision set for what was mentioned above.

I had a complete drive data corruption and even the partition table was corrupted. It had an ext4 filesystem on it. I could not recover the drive, had to wipe it clean.

Even before that time I noticed some weird problems, like I had some music files on the drive that when played would have a stutter to them. that never happened before, it was a sign that soon after, like maybe 3 months I had the corruption problem.

I remember doing some tests, and copied the same files to a USB, and played them on a different computer, and no stuttering happened. The dirve must of been say 80%-90% full. I know that I did not trim the device much if at all.

After the drive was wiped, and a new distro was installed, I ran smart tools, and drive says the wear level was 100% meaning the drive was like new, and picked up no errors at all. I am a little weary of this drive, it has a jmicron controller, and I recently purchased a new HP M700 MLC 240 gb drive as main drive. As it was so cheap, and wanted a little extra space even though I have a 2TB spinner attached as well.

The HP drive has like a 5 year warranty, but realistically I probably will never use it, with how cheap drives are now.

Yes I have read the DMLuks FAQ, and know of the why they don't like the trim function used. So far the drive seems fine, like I said it passed smart tools, I supposedly have full drive life left.

Just wanted some opinion of such a setup, and get some good insight as to what to expect.

 

[Red Squirrel]

I never really bother, for normal OS use the wear rate is so low anyway that I don't worry. Ex: it will still outlast a spindle drive by the time it fails. For mass storage (VMs etc) where it would be a bigger concern, I use spindle drives in raid.

Just make sure to disable things like Defrag and the swap file. THAT will kill the drive pretty fast.

 

[coercitiv]

Just make sure to disable things like Defrag and the swap file. THAT will kill the drive pretty fast.

No, it won't. Any modern OS is SSD aware and disables defrag by default. Meanwhile, my old 840 Pro which has been used in several systems as OS drive with swap enabled (and Photoshop workloads with occasional large swap writes) registers 16TB total host writes and 95% wear leveling count. It has already outlived the system it was bought for.

In fact every SSD I have ever bought was configured with proper swap files and is still in good working condition, including a Kingston V+ 180 and a Samsung 830 from around 2011. The Kingston drive in particular saw daily moderate usage and occasional swap files of 30GB+ since the laptop I used it with had only 8GB of RAM and was sometimes used to make large print materials.

The only thing I ever did to help the drives was to setup over-provisioning. With every new generation I keep lowering the over-provisioned percentage though, especially considering I'm moving towards larger drives for speed and get more and more free space as consequence.

 

[TheELF]

All SSDs have significantly higher raw NAND capacity than their user-accessible capacity. A "128GB" drive has a usable capacity of 128,035,676,160 bytes. 128GiB is 137,438,953,472 bytes, so you're getting access to at most 93.16% of the raw capacity of the drive. But NAND flash chips are never exactly 128Gb; they have spare area built-in to the chip to allow for defective blocks, and extra space to store error correction data.

You have it the wrong way around 128Gb drives are not 137Gib ,128Gb drives are ~119Gib as in they show up in windows as 119Gb ,an overprovisioned one that is marked as 120Gb will show up as ~111Gb.

 

[bononos]

...........
The only thing I ever did to help the drives was to setup over-provisioning. With every new generation I keep lowering the over-provisioned percentage though, especially considering I'm moving towards larger drives for speed and get more and more free space as consequence.

Do you setup overprovisioning by reserving an unused partition or keep a portion of the disk unused and unpartitioned? Is there a difference between the 2?

 

[coercitiv]

Do you setup overprovisioning by reserving an unused partition or keep a portion of the disk unused and unpartitioned? Is there a difference between the 2?

I keep a portion of the disk unused and unpartitioned. AFAIK there is a difference between the two methods you describe, or more exactly there was a theoretical difference in the way the SSD treated free partitioned space vs. free "unused" space, but that may not matter if the free partition never sees any writes - this is kinda above my knowledge level though, so maybe others can chime in.

I'm sure however that no consumer workload will see a significant performance difference between modern disks that have a healthy degree of unpartitioned space, equivalent partitioned "untouched" space or simply equivalent free space on main used partitions. By this point, as long as we're talking about good SSDs with tuned housekeeping mechanism, the difference is mostly academical.

 

[TheELF]

It's not like it's hard to do some right clicking in windows,120Gb capacity drives show up as about 110-111Gb in windows.They are not 137Gb drives that show up as 120.

 

[Billy Tallis]

It's not like it's hard to do some right clicking in windows,120Gb capacity drives show up as about 110-111Gb in windows.They are not 137Gb drives that show up as 120.

There's a difference between a 128GB drive and a 120GB drive. I gave you numbers for the former, which you're trying to refute with numbers for the latter. And Windows Explorer is the wrong tool for finding out the actual usable capacity of the drive, because it only shows you the capacity of the partition on that drive. Your 120GB drive has a total usable capacity of 120,034,123,776 bytes. There's a substantial chunk of space missing from the Windows Explorer count because of the partition table itself, the EFI System Partition, and probably a recovery partition.

 

[TheELF]

There's a difference between a 128GB drive and a 120GB drive. I gave you numbers for the former, which you're trying to refute with numbers for the latter. And Windows Explorer is the wrong tool for finding out the actual usable capacity of the drive, because it only shows you the capacity of the partition on that drive. Your 120GB drive has a total usable capacity of 120,034,123,776 bytes. There's a substantial chunk of space missing from the Windows Explorer count because of the partition table itself, the EFI System Partition, and probably a recovery partition.

No my drive is a 128Gb one but it has overprovisioning.
SSDs don't follow the size conventions of HDDs but those of RAM so all disks are 16-32-64-128 and so on in Gb.
The thing is that it doesn't have 120Gb available and 128Gb "hardware size" as you suggested.

It's not 120 GiB = 128.84901888 GB
it's 120 GB = 111.758708954 GiB

A "128GB" drive has a usable capacity of 128,035,676,160 bytes. 128GiB is 137,438,953,472 bytes, so you're getting access to at most 93.16% of the raw capacity of the drive.

 

[Billy Tallis]

No my drive is a 128Gb one but it has overprovisioning.

The manufacturer advertises it as a 120GB drive. It is not correct to refer to it as a 128Gb drive, even though the nominal raw NAND capacity on that drive is 128GiB. Drives are sold based on their usable capacities. Calling a 120GB 840 EVO a 128Gb drive is much less accurate than calling it a 120GB drive.

During IMFT's first generation of 3D NAND, there were plenty of 120GB and 128GB SSDs that had nominal raw NAND capacities of 144GiB, but nobody called them 144GB drives; they were still advertised and referred to by their usable capacity based approximately on the definition of 1GB=1,000,000,000 bytes.

SSDs don't follow the size conventions of HDDs but those of RAM so all disks are 16-32-64-128 and so on in Gb.

500GB SSDs and 500GB hard drives have the exact same usable capacity. 128GB SSDs do not have the same usable capacity as 128GB DIMMs.

 

[coercitiv]

It's not like it's hard to do some right clicking in windows,120Gb capacity drives show up as about 110-111Gb in windows.They are not 137Gb drives that show up as 120.

You're so caught up in trying to prove Billy Tallis wrong that you didn't even notice you misunderstood what he originally wrote.

He comes in and says "128GB" drives are commonly based on 128GiB worth of Flash NAND, meaning raw capacity is 128 x 1,073,741,824 bytes = 137,438,953,472 bytes and thus the drive can present itself as an "128GB" SSD with 128,035,676,160 bytes, meaning the user only directly controls 93.16% of the raw capacity of the drive, leaving ~7% to be used independently by the SSD firmware.

All SSDs have significantly higher raw NAND capacity than their user-accessible capacity. A "128GB" drive has a usable capacity of 128,035,676,160 bytes. 128GiB is 137,438,953,472 bytes, so you're getting access to at most 93.16% of the raw capacity of the drive.

You come in and drop a bombshell, an incorrect statement which you alone attribute to the previous poster.

You have it the wrong way around 128Gb drives are not 137Gib

Billy Tallis clearly stated "128 GB" drives are 128 GiB = 137,438,953,472 bytes, and yet here he is presumably having said that "128GB" drives are 137 GiB = 147,102,629,888 bytes. It's like magic, the stuff you can use to win elections.

But wait, there's more, we can accuse the man of even worse if we use another conversion to confuse the hell out of everyone, including ourselves:

You have it the wrong way around 128Gb drives are not 137Gib ,128Gb drives are ~119Gib as in they show up in windows as 119Gb ,an overprovisioned one that is marked as 120Gb will show up as ~111Gb.

120Gb capacity drives show up as about 110-111Gb in windows.They are not 137Gb drives that show up as 120.

So up until know we discussed the raw capacity of flash drives which is measured in Gibibytes (GiB), the user accessible portion which is advertised in Gigabytes (GB) and now we're introducing the net (formatted) capacity after a file system is put in place which is also calculated in Gibibytes but represented in the OS as "GB" to confuse the heck out of every living soul. Let's take this step by step for a drive that can be sold as "128GB":

1. Raw capacity of NAND --> 128GiB = 128 x 2^30 bytes = 137,438,953,472 bytes
2. Advertised capacity which is very close to the user addressable capacity --> 128GB = 128 x 10^9 bytes = 128,000,000,000 bytes marketed (128,035,676,160 bytes addressable)
3. Formatted capacity which takes user addressable space and converts back in gibibytes --> 128 GB = ~128,000,000,000 bytes = 119 GiB minus whatever capacity loss due to file system overhead.

So there we have it, how we start with a drive built from 128GiB worth of Flash and we end up with ~119 GiB worth of usable storage space after manufacturer provisioning and file system overhead are taken into account.

• Raw space of 137,438,953,472 bytes
• Windows space a bit under 128,000,000,000 bytes

This entire discussion could have been avoided by checking easy to find resources such as the Flash Memory wiki page:

an SSD marked as “64 GB” is at least 64 × 1000^3 bytes (64 GB). Most users will have slightly less capacity than this available for their files, due to the space taken by file system metadata.

The flash memory chips inside them are sized in strict binary multiples, but the actual total capacity of the chips is not usable at the drive interface. It is considerably larger than the advertised capacity in order to allow for distribution of writes (wear leveling), for sparing, for error correction codes, and for other metadata needed by the device's internal firmware.

 

[thor23]

If you're using NTFS most ssd's can use the freespace as though it were unpartitioned, if you're using a non ntfs file system that might not be the case.
Either way I still think it's better to leave 10% of your ssd unpartitioned then you don't have to worry about how much free space you have for wear leveling, especially if you're installing an SSD for someone else who might not know to leave ffree space for wear levelling.

 

[hojnikb]

If you're using NTFS most ssd's can use the freespace as though it were unpartitioned, if you're using a non ntfs file system that might not be the case.
Either way I still think it's better to leave 10% of your ssd unpartitioned then you don't have to worry about how much free space you have for wear leveling, especially if you're installing an SSD for someone else who might not know to leave ffree space for wear levelling.

SSDs have no concept of filesystem, so it really doesn't matter, what kind you use. So yes, ssd will use free space for internal work, if the data on there is invalid (ie trimmed or deleted or to be overwritten).

 

[Lucretia19]

I never really bother, for normal OS use the wear rate is so low anyway that I don't worry. Ex: it will still outlast a spindle drive by the time it fails. For mass storage (VMs etc) where it would be a bigger concern, I use spindle drives in raid.

The Crucial MX500 ssd is an exception to that claim of low wear rate, due to what appears to be a bug that causes its write amplification to be higher than necessary. This effect is easiest to observe when the host doesn't write much to the ssd, because then the ratio of useful amplification to buggy amplification is much lower.

As an example, during the 3 weeks from 1/15/2020 to 2/04/2020, my pc wrote only 138 GB to my MX500, and the Remaining Lifetime dropped from 94% to 93%. At that rate, the ssd would die far short of its 180 TB duration specification. (100 x 138 GB is only about 14 TB.) It also appeared the problem was growing worse. During the 3 weeks from 12/23/2019 to 1/15/2020, the pc wrote 390 GB and the RL dropped from 95% to 94%.

This MX500 bug isn't well known, but it correlates perfectly with a more widely known bug that many people have complained about: Current Pending Sectors occasionally changes to 1, and changes back to 0 several seconds later. (Crucial tech support claims that's not a bug.) By sampling SMART data at a high rate, I saw that Current Pending Sectors is 1 while the FTL controller is in the process of writing NAND pages at high speed: multiples of about 37,000 NAND pages (approximately 1 GB) at a speed of approximately 5 seconds per GB. (I'm pretty sure the FTL controller is moving data during those bursts -- reading and writing, not just writing.)

I assume one of the reasons why the bug isn't more widely known is that most computers write more to the ssd than mine does. So their ssd's ratio of useful amplification to buggy amplification is higher than mine, and the buggy amplification goes unnoticed. Another reason may be that some people turn off their pc most of the time; for those people the Remaining Life won't drop fast relative to realtime, and the faster-than-necessary decrease of Remaining Life goes unnoticed.

I found a "simple" way to mitigate the bug: selftests. Starting around the beginning of March 2020, my pc has been continually running a task that consists of an infinite loop (with a 20 minutes period) that calls smartctl.exe (part of Smartmontools) to command the ssd to selftest. Apparently selftest is a higher priority routine than the buggy FTL routine (which I assume is the wear-leveling routine or the garbage collection routine) so the buggy routine gets much less runtime to do damage. The loop aborts each selftest after 19.5 minutes and pauses 30 seconds before the loop repeats. My hunch is that the pauses between selftests allow enough runtime to the wear-leveling and garbage collection routines to keep the ssd healthy; if this hunch were wrong, I think one of my SMART logs -- which samples once per second during each pause -- would show many more write bursts during the pauses... but the log shows that most of the pauses have no write bursts.

With the selftests regime active, it took 7 months (3/13/2020 to 10/19/2020) for Remaining Lifetime to drop from 92% to 91%, during which the pc wrote 1,531 GB. (Since 10/19/2020, another 9.5 months have elapsed and it hasn't yet dropped to 90%, with 1,064 GB more written by the pc. I expect it will reach 90% in September or October, based on my observations of Average Block Erase Count, which reached 148 on 7/24/2021.)

There appears to be no performance loss while a selftest is running, according to CrystalDiskMark. But the ssd does appear to consume about 1 watt extra, because the ssd won't enter low power mode while a selftest is running.

Regarding the OP's original question... I see no downside to overprovisioning, as long as you don't run out of available storage space. (At that point, it may be time to buy a larger drive.)