MX300: Overprovisioning Question

SOLVED
Kilobyte Kid

Re: MX300: Overprovisioning Question

msecli is the offocial utility for Linux and Windows delivered by Micron (Crucial is a Micron brand).

This tool is delivered with a PDF manual that explains how to over-provision a compatible drive.

The command msecli -L -d lists all available supported devices.

 

Here are my six SSDs before over-provisioning:

root@calculon:~/msecli_Linux_64bit# ./msecli -L -d

Device Name          : /dev/sdc
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdd
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sde
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdf
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdg
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdh
Total Size           : 525.11GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Listing the detailed drive information is retrieved successfully
CMD_STATUS   : Success 
STATUS_CODE  : 0 

Copyright (C) 2016 Micron Technology, Inc.

Before executing the over-provisioning procedure, the informations gathered suggest a free space of exactly 525.11GB.

Native Max LBA has to be taken as the 100% of the total. If I want to over-provision 25% I should keep the remaining 75% over 1025610767 LBAs (about 769208075). This is the right command (including the sanitize operation, as suggested by the official manual):

root@calculon:~/msecli_Linux_64bit# ./msecli -M -o 769208075 -z -n /dev/sdc

I executed this command for each o my devices (/dev/sdc, /dev/sdd, ..., /dev/sdh). After the provisioning, the previous command returns a different total size:

root@calculon:~/msecli_Linux_64bit# ./msecli -L -d

Device Name          : /dev/sdc
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdd
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sde
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdf
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdg
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Device Name          : /dev/sdh
Total Size           : 393.83GB
Drive Status         : Drive is in good health
SMARTEnabled         : Yes
Est. Life Remaining  : 100%
TCG Status           : Deactivated
Native Max LBA       : 1025610767

Listing the detailed drive information is retrieved successfully
CMD_STATUS   : Success 
STATUS_CODE  : 0 

Copyright (C) 2016 Micron Technology, Inc.

msecli is useful also for firmware update but I haven't tried it yet.

 

 

Anyway, have you a reference about the factory over-provisioning? I contacted the official support here in Italy and they told me the drives must be manually over-provisioned using Crucial Storage Executive. I tested the disks using fio and can affirm that they weren't overprovisioned simply looking at the various stats and regression models.

 

JEDEC Jedi

Re: MX300: Overprovisioning Question

[ Edited ]

I think what you're failing account for is that Linux uses the modern definition of a GB where 1k = 1000. Smiley Happy

Under Windows your drive would show as 500GB because it uses the old school technique of 1k = 1024 

The maths I did above is using WIndows style defintions of 1K (now known as a kibibyte)

_______________________________________
How do I know what memory to buy?
Shop for your region: US | UK | EU | France | Global
I think my memory is bad. What do I do now?
FAQs and Top Forum Solutions
We want your feedback! Post in the Suggestion Box
Did a user help you? Say thanks by giving Kudos!
Still need help? Contact Customer Service
Want to be a Super User?
Kilobyte Kid

Re: MX300: Overprovisioning Question

[ Edited ]

I'm talking based on the answer that the official Crucial support gave me and based on my test results.

Anyway, msecli reports the same size both on Linux and Windows.

 

I tested the six disks on a IBM X3650 M4 server (2 x Intel Xeon E2690 @ 2.90Ghz) and 96GB RAM in JBOD mode (no RAID configuration).

The software used is fio on Ubuntu 16.10 Server (kernel 4.8).

Tests was of 1 minute each per work-load per disk and I tested the factory-defaults against 6 different over-provisioning quotas: 5%, 10%, 15%, 20%, 25% and 30%. The main purpose wasn't to test write amplification effects but short-run work-loads against factory defaults.

 

The tested workloads was of two types: 4k random reads and 8k 70% random reads and 30% random writes.

Here are the read IOPS averaged over the various combinations of work-loads, IO Depths and factory-defaults against over-provisioning (for all over-provsioning reserved space):

 

[ 4k - 100% random reads ]

  • IO Depth of 1: factory defaults 6794 iops, over-provisioned 10943 iops (61% faster)
  • IO Depth of 2: factory defaults 13369 iops, over-provisioned 25667 iops (92% faster)
  • IO Depth of 4: factory defaults 25339 iops, over-provisioned 37731 iops (49% faster)
  • IO Depth of 8: factory defaults 36782 iops, over-provisioned 38148 iops (3.7% faster)
  • IO Depth of 16: factory defaults 38376 iops, over-provisioned 38070 iops (<1% slower)
  • IO Depth of 32: factory defaults 38371 iops, over-provisioned 38097 iops (<1% slower)

[ 8k - 70% random reads ]

  • IO Depth of 1: factory defaults 4601 iops, over-provisioned 6418 iops (40% faster)
  • IO Depth of 2: factory defaults 8630 iops, over-provisioned 12741 iops (48% faster)
  • IO Depth of 4: factory defaults 14386 iops, over-provisioned 16684 iops (16% faster)
  • IO Depth of 8: factory defaults 17028 iops, over-provisioned 17191 iops (1% faster)
  • IO Depth of 16: factory defaults 17248 iops, over-provisioned 17250 iops (the same)
  • IO Depth of 32: factory defaults 17217 iops, over-provisioned 17254 iops (the same)

The above data is showed in this simple graph:

 

overprovisioning_gain.png

 

The conclusion is that factory-defaults provide slower performance for small IO Depth values and over-provisioning via msecli improves the device IOPS. Latency and bandwidth benefits  from this operation too.

 

Do you have any link or resource that documents the presence of factory over-provisioning on those devices?

Kilobyte Kid

Re: MX300: Overprovisioning Question

Thanks for doing those tests. Just to be clear, the performance gain was the same for all the over-provisioning quotas? In other words, no difference observed between 5% and 30%?

Kilobyte Kid

Re: MX300: Overprovisioning Question

[ Edited ]

There were little differences (few MB/s in terms of bandwidth) and found that overprovisioning at 25% was the fastest for my configuration. I don't have the numbers at hand in this moment but the differences were significant from the factory defaults (aka no-provisioning) - I run a statistical model to account for block size, io depth, overprovisioning and interactions.

 

You should see difference in the long term, after lot of TB written to the disks. In other words, larger overprovisioning sizes should ensure longer lifetime for the drives and less performance degradation.