Some consumer SSDs are moving to a 4k 'advance format' physical block size

February 19, 2018

Earlier this month I wrote an entry about consumer SSD nominal physical block sizes, because I'd noticed that almost all of the recent SSDs we had advertised a 512 byte physical block size (the exceptions were Intel 'DC' SSDs). In that entry, I speculated that consumer SSD vendors might have settled on just advertising them as 512n devices and we'd see this on future SSDs too, since the advertised 'physical block size' on SSDs is relatively arbitrary anyways.

Every so often I write a blog entry that becomes, well, let us phrase it as 'overtaken by events'. Such is the case with that entry. Here, let me show you:

$ lsblk -o NAME,TRAN,MODEL,PHY-SEC --nodeps /dev/sdf /dev/sdg
NAME TRAN   MODEL            PHY-SEC
sdf  sas    Crucial_CT2050MX     512
sdg  sas    CT2000MX500SSD1     4096

The first drive is a 512n 2 TB Crucial MX300. We bought a number of them in the fall for a project, but then Crucial took them out of production in favour of the new Crucial MX500 series. The second drive is a 2TB Crucial MX500 from a set of them that we just started buying to fill out our drive needs for the project. Unlike the MX300s, this MX500 advertises a 4096 byte physical block size and therefor demonstrates quite vividly that the thesis of my earlier entry is very false.

(I have some 750 GB Crucial MX300s and they also advertise 512n physical block sizes, which led to a ZFS pool setup mistake. Fixing this mistake is now clearly pretty important, since if one of my MX300s dies I will probably have to replace it with an MX500.)

My thesis isn't just false because different vendors have made different decisions; this example is stronger than that. These are both drives from Crucial, and successive models at that; Crucial is replacing the MX300 series with the MX500 series in the same consumer market segment. So I already have a case where a vendor has changed the reported physical block size in what is essentially the same thing. It seems very likely that Crucial doesn't see the advertised physical block size as a big issue; I suspect that it's primarily set based on whatever the flash controller being used works best with or finds most convenient.

(By today, very little host software probably cares about 512n versus 4k drives. Advanced format drives have been around long enough that most things are probably aligning to 4k and issuing 4k IOs by default. ZFS is an unusual and somewhat unfortunate exception.)

I had been hoping that we could assume 512n SSDs were here to stay because it would make various things more convenient in a ZFS world. That is now demonstrably wrong, which means that once again forcing all ZFS pools to be compatible with 4k physical block size drives is very important if you ever expect to replace drives (and you should, as SSDs can die too).

PS: It's possible that not all MX500s advertise a 4k physical block size; it might depend on capacity. We only have one size of MX500s right now so I can't tell.


Comments on this page:

By Javier at 2019-10-29 05:29:24:

Just found this after landing on your blog from a google search of 'MX500' and 'Pending Sectors', while reading various related articles this one actually made me look:

# lsblk -o NAME,TRAN,MODEL,PHY-SEC,REV,SERIAL --nodeps /dev/sd[bcdef]
NAME TRAN   MODEL           PHY-SEC  REV SERIAL
sdb  sata   CT1000MX500SSD1    4096 023  1845E1D5EC2D
sdc  sata   CT1000MX500SSD1    4096 023  1845E1D63FE1
sdd  sata   CT1000MX500SSD1     512 023  1844E1D4FA79
sde  sata   CT1000MX500SSD1     512 023  1845E1D610B1
sdf  sata   CT1000MX500SSD1    4096 023  1920E203CC08

I'm pretty surprised tbh. I had expected them all to be 4K, and only had 1 drive of the set that came with a 022 firmware (upgraded), so didn't even check and aligned all things to 4K. The difference between the closest SN# where physical sector size changes (sde->sdb) is just 21428, or a bit over 20k drives in-between. And I'm also getting the sporadic "1 pending sectors" every now and then, usually gone after a reboot.

Written on 19 February 2018.
« Memories of MGR
I've now received my first spam email over IPv6 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Feb 19 00:34:40 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.