WEBVTT 00:00:00.000 --> 00:00:04.240 We're used to getting revisions of computer standards fairly regularly. Think about how 00:00:04.240 --> 00:00:09.840 many versions of USB, DDR, and PCI Express we've been through. But we haven't had to put much 00:00:09.840 --> 00:00:15.840 thought into NVMe so far, as there's only been one major version of it. Until now, 00:00:15.840 --> 00:00:22.480 as the NVMe 2.0 standard has just been released. In case you're out of the loop, NVMe, or Non-Bolatile 00:00:22.480 --> 00:00:28.160 Memory Express, is the protocol that PCI Express connected storage drives use. Because it's much 00:00:28.160 --> 00:00:33.440 faster than the older SATA standard, it's enabled those gaudy four-figure throughput numbers you see 00:00:33.440 --> 00:00:39.040 on manufacturer spec sheets for M.2 drives. And the NVMe 2.0 specification is bringing some new 00:00:39.040 --> 00:00:44.000 features to the table. So let's dive right in. One of the major improvements is for something 00:00:44.000 --> 00:00:49.840 called zoned namespaces. And that might sound like some kind of forward-thinking therapy collective, 00:00:49.840 --> 00:00:55.680 but it's actually a system designed to address some of the biggest issues with SSDs. You see, 00:00:55.680 --> 00:01:00.720 even though SSDs are a lot faster than old-school spinning hard drives, there's a significant 00:01:00.720 --> 00:01:06.720 amount of inefficiency under the hood. Because the cells in an SSD can only be written to so many 00:01:06.720 --> 00:01:12.720 times before they wear out for good, the SSD's internal logic has to move data around in a process 00:01:12.720 --> 00:01:18.320 called wear leveling to make sure certain cells don't exhaust their lifespans more quickly than 00:01:18.320 --> 00:01:25.360 others. Additionally, SSDs can't directly overwrite cells. Instead, cells have to have their data 00:01:25.440 --> 00:01:32.000 erased first. And this has to be done in groups of cells. So any data in that group that the system 00:01:32.000 --> 00:01:38.320 needs to preserve must be copied to an empty area. SSDs reserve a certain amount of space called 00:01:38.320 --> 00:01:44.560 over-provisioning to support these data operations, meaning a significant amount of storage is inaccessible 00:01:44.560 --> 00:01:51.280 to the user. NVMe 2.0's zoned namespaces help alleviate this situation by allowing programs 00:01:51.280 --> 00:01:57.680 to reserve specific physical areas on the SSD and write data for that program sequentially. 00:01:57.680 --> 00:02:02.720 Without zoned namespaces, the SSD itself would be in charge of what data goes where. And this 00:02:02.720 --> 00:02:08.560 often results in a specific program's data being scattered all over the drive, meaning that any 00:02:08.560 --> 00:02:14.560 changes to that data could require lots of those read, copy, delete actions that use a large amount 00:02:14.560 --> 00:02:21.040 of over-provisioned space. But with zoned namespaces, a smaller physical footprint per program 00:02:21.040 --> 00:02:27.360 means the SSD won't have to over-provision as much space, nor do so many reads and writes, 00:02:27.360 --> 00:02:32.960 meaning effectively larger drives, with better endurance for the same cost. And programs could 00:02:32.960 --> 00:02:38.880 also see a performance boost from zoned namespaces as SSDs read and write sequential data faster than 00:02:38.880 --> 00:02:44.480 they do random data. So not only is this good for consumers like you and me, but larger organizations 00:02:44.480 --> 00:02:49.760 should see an even greater benefit than us, since when you're running lots of SSDs in parallel, 00:02:49.760 --> 00:02:55.920 such as inside a gigantic server farm, having that much wasted space and latency 00:02:55.920 --> 00:03:01.440 can have a significant negative impact. Not to mention the direct cost of having to replace drives 00:03:01.440 --> 00:03:06.560 that wear out. The second significant benefit of NVMe 2.0 that we're going to discuss today is 00:03:06.560 --> 00:03:13.040 its surprising support for mechanical hard drives. But why would it support mechanical hard drives? 00:03:13.600 --> 00:03:19.440 Even higher-end drives can't come anywhere close to using the full bandwidth of plain old 00:03:19.440 --> 00:03:25.600 SATA. So what gives? It turns out that recent advances in hard drive manufacturing have allowed 00:03:25.600 --> 00:03:31.680 drives to read data off the platters more quickly, partly due to improvements in the actuators that 00:03:31.680 --> 00:03:36.880 move the drive parts around, and partly due to fitting more data on the platters themselves, 00:03:36.880 --> 00:03:41.760 through techniques like heat-assisted magnetic recording, which you can learn about up here. 00:03:42.640 --> 00:03:46.960 Hammer time. This means that some hard drives that are just starting to hit the market 00:03:46.960 --> 00:03:52.320 can get sustained transfer rates above 500 megabytes per second sequentially, 00:03:52.320 --> 00:03:58.160 which is comparable to SATA-based SSDs. NVMe 2.0 will provide enough bandwidth 00:03:58.160 --> 00:04:03.360 to ensure newer hard drives can max out their potential, especially important in larger settings 00:04:03.360 --> 00:04:08.240 that use lots of hard drives for mass storage. They can share data among themselves quickly. 00:04:08.240 --> 00:04:11.920 Of course, because the NVMe 2.0 spec was released recently, 00:04:11.920 --> 00:04:17.120 it'll be a while before we see products that support it. But hopefully the result will be 00:04:17.120 --> 00:04:23.600 larger, cheaper drives for your home PC, and quicker, more reliable access to cloud services. 00:04:23.600 --> 00:04:27.520 I just wouldn't expect Disney to slash the price of your streaming subscription 00:04:27.520 --> 00:04:31.280 with the money they're saving on drives. World doesn't tend to work like that. 00:04:31.840 --> 00:04:35.280 So thanks for watching guys! If you liked this video, hit like, hit subscribe, 00:04:35.280 --> 00:04:39.520 and hit us up in the comments section with your suggestions for topics we should cover in the 00:04:39.520 --> 00:04:40.000 future.