耐力组管理¶

标题：Endurance Group Management

日期：2019/09/07

作者：Mark Carlson

链接：https://www.youtube.com/watch?v=UlK7kisHnFI

注意：此为 AI 翻译生成 的中文转录稿，详细说明请参阅仓库中的 README 文件。

备注：这是 NVMe spec 里面关于存储模型-耐力组的讨论，PDF 没看懂就找点其他资料。

主讲人介绍及议题概述¶

好的，我是 Mark Carlson，来自东芝存储（Toshiba Memory）。Paul 和我将要就这个“耐力组管理”（Endurance Group Management）的话题进行一次演讲。这个议题也包含了 NVM 集（NVM set）管理。当 NVM 集和耐力组在 NVMe 1.4 规范中被引入时，其功能是相当有限的，因为 SSD 制造商会交付一个预先配置好 NVM 集的驱动器。作为客户，你实际上对于这些 NVM 集的位置以及它们的大小，只有非常有限的控制能力。

我们在这项新工作中正在做的，是允许对 NVM 集和耐力组进行更精细的控制。NVMe 1.4 版本虽然有耐力组的概念，但它只是驱动器告诉主机，驱动器内部正在对哪些区域进行磨损均衡（wear leveling）。结果就是，在某些情况下，主机必须跨越不同的 NVM 集进行磨损均衡，这完全取决于制造商交付给你的产品是什么样的。所以，我们正在这个领域增加更多的能力。我就不念摘要了，那是一张我们俩的漂亮合影，我们直接进入正题，好吗？

用例与动机¶

一些用例包括了更灵活的 IO 确定性（IO determinism），就像我刚才说的那样。现在，主机不再是从制造商那里获得一个固定的配置，而是可以对事物的布局、哪些介质（media）进入哪个集合、以及驱动器和主机的责任划分，拥有更多的控制权。你可以把它想象成一个可以调节的旋钮，你可以把它完全转到一边，让驱动器来完成所有的磨损均衡工作；或者你也可以把它调到中间某个位置，分块处理。所以我们在这里做的，就是提供一个精细的控制旋钮，给予主机更多的控制权。这对于一些大客户来说，是一件大事。

最终，你做这些事情的目的是为了划分驱动器的容量。请记住，IO 确定性的最初目标，正如 Nick 所说，是为了消除或隔离驱动器上不同区块之间的活动。如果整个驱动器是一个 40TB 的大区块，那么你会有无数个不同的应用程序同时访问同一块介质。

另一件事，从驱动器制造商自私的角度来看，是我们不想为每个客户提供不同的 SKU（库存单位）。我们希望只出货一种 SKU，然后由客户按照他们想要的方式进行配置。所以，这才是驱动器供应商实现这个功能的真正动机，即他们不必为不同的客户准备不同的配置。

核心概念：命名空间、NVM 集、耐力组和域¶

那么我们具体在谈论什么呢？命名空间（Namespaces）包含某种形式的逻辑块阵列。未来，它也可能是键值（key value）类型的命名空间。当然，Dave 之前也谈到过分区命名空间（zone namespaces），作为一种将逻辑块组织起来的不同方式。然后，包裹着命名空间的是所谓的 NVM 集（NVM sets）。在一个 NVM 集内部，你可以有多个命名空间，或者如果你愿意，也可以只有一个。

再往外层，包裹着 NVM 集的是耐力组（Endurance Groups）。同样，你可以在一个耐力组里有多个 NVM 集，也可以是一对一的关系。然后，不是在这次工作中引入，而是在 Fred 正在做的工作中引入的，是域（Domains）的概念。它允许你在一个域中拥有一个或多个耐力组。通常情况下，一个单独的 SSD 可能只有一个域，而一个巨大的、房间大小的 NVM 设备可能会有多个域，从而拥有多个故障域。

工作原理与配置¶

如果你看旧的 NVM 集，我们会根据驱动器内部的通道（channels）来对齐它们。我们通过通道连接这些介质单元（media units），然后一个耐力组可能只对应一个 NVM 集。右边的关键点是一个新概念，叫做

介质单元（media unit）。介质单元可能是一个芯片裸片（die），可能比裸片更小，也可能比裸片更大，但它基本上是驱动器自身进行磨损均衡的最小粒度的 NAND 或持久性内存单位。驱动器能够做到的磨损均衡就到这个粒度，不能再小了。

所以，如果你将多个介质单元组合在一个耐力组中，这意味着驱动器正在对该耐力组内的所有这些介质单元进行磨损均衡。但反过来说，如果你有多个耐力组，那就意味着主机需要跨越这些耐力组进行磨损均衡。这正是耐力组最初的意图：将一部分磨损均衡的责任推给主机，让主机来决定是想将整个驱动器作为一个整体来均衡磨损，还是让每个 NVM 集由驱动器自行均衡。

最初，这同样源于 IO 确定性的需求。你希望根据容量需求来创建 NVM 集。例如，一些客户的应用程序有 1TB 的工作集，所以他们希望创建 1TB 或更小的 NVM 集。在这种情况下，驱动器在每个 NVM 集内部进行磨损均衡，你有四个耐力组和四个 NVM 集。正如我所说，如果主机希望整个驱动器能同时耗尽寿命，他就必须跨越这些 NVM 集和耐力组进行磨损均衡。

这种配置通常在驱动器的初始部署阶段完成。当然，你也可以重新调整驱动器的用途并重新配置这些 NVM 集，但大多数情况下这是一次性操作。然后，我们提供了几种不同的耐力组和 NVM 集的配置供你选择。这些都是驱动器制造商提供的已知支持的配置。最终，我们或许能达到可以让你像填写宾果卡一样读写任何你想要的配置。但就目前而言，这对 SSD 供应商来说是一个测试和认证的噩梦。所以我们从那种“任意配置”的想法上退了一步。而且，驱动器可能仍然只支持几种不同的配置，比如半 TB 和 1TB 的 NVM 集。这并不是对驱动器能力的真正限制。你知道，客户想要什么，我们当然会提供什么，对吧，Lee？。

那么，如果主机想自己完成所有的磨损均衡呢？你可以采用像右边这样的配置，其中每个耐力组包含一个 NVM 集和一个命名空间。这基本上意味着主机在这里完成了所有的磨损均衡工作。主机会介入并判断每个微小介质单元的磨损情况。他会注意到某个单元比其他单元磨损得更快，然后他会开始使用其他的介质单元，而不是他一直在用的那个。例如，这对于分区命名空间（zoned namespaces）来说可能是一个理想的配置。每个分区命名空间都有自己的磨损信息，你可以用它来决定是继续写入该分区，还是开始转移到其他地方。

当然，还存在各种各样的配置。同样，如果驱动器供应商支持这些不同的配置，他会把它们放在配置表中供你选择。因此，一个 SSD 可以使用一些介质单元来提供少量的高速容量，而将其余单元用于更高密度存储。如果你像这样跨通道配置一个 NVM 集，你会获得更好的带宽。如果你追求带宽，这可能是个不错的配置方式。但如果你追求隔离性，这就不是个好主意了，因为每一次写入都会与其他介质单元争夺那些通道。

好了，现在 Paul 将接手，告诉你们我们是如何实现这一切的。

两种管理模型：直接管理与基于容量的管理¶

好的，在我深入讲解我们如何暴露这种组织结构的细节之前，我先谈谈另一个不同的用例，这个用例来自存储系统。如果你的 NVM 子系统是一个装满了机架的房间，那么你可能不会去操作单个的介质单元。相反，你真正想要的是能够通过简单地指定它们应该有多大，来配置、创建和调整耐力组和 NVM 集的大小。这就是我们所说的“

基于容量的耐力组管理”（capacity endurance group management）。当然，在最终的技术提案出来之前，这些名称可能会改变。

其要点是，你将拥有一个包含控制器和一定数量非易失性介质的域。这是一个从“域和分区”（domains and partitioning）提案中引入的概念，该提案即将整合进来。容量将来自任何可用的存储。在一个大型存储系统中，它可能来自后端的 SCSI 磁盘，而存储系统将它们呈现为一个跨越各种介质的条带化命名空间，你并不知道底层是什么。此外，还可以在耐力组内部创建 NVM 集，以及删除 NVM 集、命名空间和耐力组。

所以，我们最终得出了两种方法，我之前已经稍作预告。

直接耐力组管理 (Direct endurance group management)：主机查看所提供的配置，并通过指定其名称来选择其中之一。
基于容量的耐力组管理 (Capacity-based endurance group management)：就像我刚才说的，你直接请求“给我一个这样大小的耐力组”，或“给我一个这样大小的 NVM 集”。

直接耐力组管理主要用于驱动器。基本上，如我所说，它是一组固定的配置。在当前阶段，选择一个配置通常会贯穿驱动器的整个生命周期。因为如果你使用了一部分容量一段时间后想重新配置，事情会变得非常复杂。你可能有一些介质单元（可以想象成裸片）具有不同的磨损程度，如果在重新配置时不小心，可能会引发问题。所以，这个问题我们暂时推迟到了未来的版本。

我还要指出，直接耐力组管理确实满足了超大规模数据中心（hyperscalers）的需求。但我们的做法是一次性选择一个完整的配置，而不是先配置一个耐力组，看看剩下什么，再配置另一个。同样，这个功能也不会出现在第一个版本中。

我们目前称之为“耐力组管理命令”（endurance group management command），当然，这个名字也可能会变。它有两种类型的操作。一种是“选择介质单元配置”（select media unit configuration），它会从驱动器告知主机的指定配置中选择一个。

另一方面，对于存储阵列（storage arrays），有一组四个操作。

创建耐力组（Create an endurance group）。
从一个指定的耐力组中，创建一个指定大小的 NVM 集。
删除一个 NVM 集。
删除一个耐力组。当你删除一个 NVM 集时，它会自动删除其中可能仍然存在的任何命名空间。你可以先创建一个耐力组，然后在其中创建 NVM 集，之后应用现有的命名空间管理命令在 NVM 集中创建命名空间。但是，如果你删除一个耐力组，它会带走其内部所有的 NVM 集以及任何现存的命名空间。这就是我们前进的大致方向。

配置描述符¶

那么，你如何描述这些可以组织 SSD 的配置呢？回想一下 Mark 展示的那张图，一个耐力组包含一个或多个 NVM 集，我们的描述结构也将遵循这个模式。对于任何特定的配置，最高层级的信息是关于耐力组的，我们称之为

耐力组配置描述符 (endurance group configuration descriptor)。你能从中得到什么信息呢？

容量调整因子 (Capacity adjustment factor)：这是我们从 UFS 规范中借鉴来的一个概念，它允许我们指定你希望这个耐力组以例如 TLC、QLC 或 SLC 模式运行。它基本上是一个比率，表示为了获得指定的耐力组容量，你需要使用多少实际的 NVM 容量。
总耐力组容量 (Total endurance group capacity)。
备用容量 (Spare capacity)：一个从 SMART 数据中借鉴过来的概念。
耐久性估算 (Endurance estimate)：表示这个组还有多少剩余寿命。然后，这个耐力组内部会有一个或多个 NVM 集。再回想一下我们看过的图，有一个控制器，然后从它下面延伸出若干通道。那么，哪些通道会进入这个耐力组呢？如果你记得那个垂直分区的例子，也就是 IO 确定性的例子，你有一个单一的通道进入一个耐力组，下面连着若干介质单元；然后旁边是另一个通道，进入一个不同的耐力组。或者，你也可以像 Mark 展示的那样，将耐力组横跨所有通道进行条带化，这样每个通道都可以被每个耐力组使用。所以，会有一个

通道描述符列表 (list of channel descriptors)，然后对于每个通道，会有一个通过该特定通道访问的介质单元列表。

最后，到了最底层，

介质单元状态描述符 (media unit status descriptor) 将包含以下信息：一个标识符、它所在的域的标识符、它所属的耐力组和 NVM 集、从耐力组继承的容量调整因子。此外，还有来自 SMART 描述的特性，如可用备用空间、已使用百分比，以及连接到该介质单元的通道数量。目前，我还没听说过有任何产品能让两个通道同时与一个裸片通信，但我们试图为未来保留灵活性。

未来展望与未包含的功能¶

现在，回到我们需要满足存储阵列厂商需求的部分，也就是另一种模型：基于容量的耐力组管理。这允许主机动态地创建和删除耐力组及 NVM 集，而无需真正关心背后是 SSD 还是旋转的机械硬盘。

这就是那个命令，我现在想谈谈下面为存储阵列设计的操作部分，这些我之前已经总结过了。

创建耐力组（指定大小）。
创建 NVM 集（指定大小）。
删除 NVM 集（指定是哪一个）。
删除耐力组。我们差不多要结束了，所以会有充足的时间提问。但现在我想谈谈我们

不打算在这里涵盖的内容。

纠错 (Error correction)：正如 NetApp 的那位先生一直提醒我们的，如果他不知道 SSD 内部有多少可用的冗余，他就必须在更高的层级上构建冗余，并将其条带化到他能访问的磁盘上。SSD 内部提供了何种程度的纠错能力？这是我们不知道的。我们试图找出一个好的方式来表示它，但发现变量太多，所以决定将其推到未来。一旦我们对 SSD 内部存储的表示方式有了更多经验，我们就可以回过头来解决这些问题。
增量配置 (Incremental configuration)：如果你想在单个 SSD 内部增量地配置耐力组，而不是一次性选择一个配置来固定所有裸片？这需要一些思考。我们不知道到底有多少人会真正使用这个功能，所以也推迟到了未来。
重新配置 (Reconfiguring)：如果你使用 SSD 一段时间后，不同的介质单元有了不同的磨损程度？你如何能为可能不同的配置重新利用那个驱动器？这其中涉及到很多复杂性，例如理解一个以 SLC 模式运行的耐力组的磨损量，与另一个以 QLC 模式运行的裸片的磨损量之间的关系。这，正如我一位教授曾经说过的，“非常不平凡”（highly non-trivial）。所以，这同样被推迟到了未来。
更低层级的组织：我们提出了一个抽象概念叫“介质单元”。但组织结构有多个层级，介质单元不一定就是一个裸片，它可能是一个平面（plane），也可能是几个裸片的组合。那么，是否能够指定比介质单元更低层级的组织结构会有意义呢？我们得再看看。所以如果我们要做，那也会在未来的提案中。
分区到介质单元的映射：最后，你如何处理分区（zones）到介质单元的映射？这能否带来任何好处？这里面有很多复杂性，我们甚至还没开始讨论。所以这些都是未来可能的工作。

问答环节 (Q&A)¶

观众：所以，我想我们现在可以提问了。你提到你们推迟了对单个 SSD 进行重新配置的功能，但似乎又允许对存储阵列进行重新配置。对。那么，存储阵列难道不存在同样的历史磨损问题吗？如果你删除一个耐力组，想要重新利用阵列中的所有介质，你必须知道底层介质的历史记录。

Paul：是的，没错。当你说的历史记录，你指的是磨损情况，对吧？是的，我们为每个介质单元提供了一个磨损属性，你可以去查看它，然后组合出一个，比如说，磨损不太严重的耐力组。而且我想指出，目前存储阵列如果是由单个 SSD 组成的，它们可以去查看 SMART 数据来了解这些信息。NetApp 的那位先生想对此做些补充吗？不。好的。反正他也没有麦克风。

观众：好的。那我要刻薄一点，问第一个我想大家都很想知道的问题。这项技术，分区命名空间（Zoned Namespaces），会扼杀开放通道（Open Channel）吗？

主讲人：呃，我想说，绝对不会。我认为我在演讲中试图展示的是，新的用例正在涌现，对吧？市场上仍然有一些人，一些非常重要的人，相信我们需要开放通道那样的模型。所以我不认为这是一个“我们或他们”的问题，而是两者共存。分区命名空间（ZNS）是处理一个特定用例的方式，即人们想要一个流式的、顺序的，你知道，顺序写的模型。这是一个特定的需求。我们认为它足够重要，所以把它剥离出来，为它创建了一种设备类型。本质上就是这样。但它不会，所谓的“扼杀”开放通道。

Mark Carlson：别忘了我之前谈到的那个“旋钮”。开放通道是把旋钮完全转到一边，主机完全控制。而以前的 NVMe 是把旋钮转到另一边，主机毫无控制权。我们现在做的，是给予主机灵活性，可以向不同方向转动这个旋钮。这比非此即彼要强大得多。

观众：关于同一个话题，开放通道 vs 分区命名空间，我有一个评论。我的看法是，分区命名空间只是，不，我不是要贬低它，它只是一个改良版的开放通道。

主讲人：你能靠近点麦克风吗？

观众：好的。它有点像是… （主持人：吃了那个麦克风！）好的，我认为分区命名空间是开放通道的转世或改良版本。它抽象了一些东西，比如说，驱动器仍然可以重新定位一个分区（zone）同时保持相同的分区ID。所以它可以做分区级别的重映射，而不是做细粒度的重映射。这可能会带来一些好处，比如，这可能允许驱动器自己做磨损均衡，而对应用程序或主机是不可见的。对吗？

主讲人：是的，我或多或少同意你的说法。我的看法是，对我来说，分区命名空间或者说分区块模型（zone block model），是一种主机和设备之间协作的 FTL（闪存转换层）。设备仍然在做垃圾回收和磨损均衡。而主机有它自己的 FTL，可能在文件系统或主机层。它也在做一些分区的垃圾回收，两者在协作。而在完全的开放通道模型中，所有这些功能都从驱动器中移除了，主机做所有的事情。所以我认为这是一个不同的用例，而不是一个“非此即彼”的选择。

观众：你之前提到你们借鉴了 UFS 作为文件系统工作的灵感。你们还从哪些其他文件系统中获得了影响？你认为在各个平台（如 Linux、Windows 等）上会使用哪些文件系统？

Paul：我提到 UFS 只是特指用于区分 QLC 和 SLC 的伸缩因子。就是那个容量调整因子（capacity adjustment factor）。我只谈了那一点。我的意思是，如果你要把一个能够以 MLC、TLC、QLC 模式运行的单元，用 SLC 模式来操作，你需要提供一个伸缩因子，来说明你要消耗多少容量才能在 SLC 模式下运行。因为这最多可能是你在 QLC 模式下能获得的存储量的十六分之一。但我关于 UFS 的观点仅限于此，基本上只是一个公式。

观众：我想问一下关于主机管理模式，就是你把那个“旋钮”完全转到主机那边的情况。如果发生电源故障，你很可能会损坏那些驱动器，不是吗？如果你没有办法恢复你在主机端 FTL 里的所有信息的话。你需要一些 NVRAM 之类的东西。

主讲人：你是指主机管理模式吗？是的，如果完全由主机管理，你需要在主机上有一些 NVRAM 之类的东西来追踪状态，如果掉电，你所有的驱动器都会坏掉，对吧？嗯，我不确定我能给你一个完美的答案。也许其他人可以。我们正在研究电源故障模型，比如可以从一个分区中恢复什么，分区处于什么状态等等。所以我认为有办法管理它，但我不太确定能回答你的问题。我之前提到过 DRAM 会变得更多。如果 DRAM 更多，那么你就需要更多的电容。不，是更少的 DRAM，对吧？我是说，这里必须有一些硬件解决方案。它不可能全靠软件然后就神奇地工作了。

主讲人：任何来自主机的关于系统即将关机的提示都会非常有帮助。

观众：我还在努力理解 NVM 集和耐力组之间的区别。所以我的理解是，一个耐力组可以有一个或多个 NVM 集。但它到底实现了什么功能呢？

Mark Carlson：NVM 集最初是实现两个不同 NVM 集之间隔离的一种方式。通过最新的工作，我们稍微软化了这一点。你看，在这种配置下，它们是隔离的，因为每个 NVM 集都在不同的通道上。所以当我写入一个 NVM 集时，它不会与另一个 NVM 集冲突。这样我就可以拿一个驱动器，让四个应用程序同时访问它，而每个应用程序都看不到来自其他应用程序工作的任何干扰。而耐力组只是一种说明“驱动器自身在对什么范围进行磨损均衡”的方式。这意味着，在这种情况下，如果主机希望整个驱动器同时耗尽，它就必须跨越这些耐力组进行磨损均衡。但这并不是主机可能设想的唯一磨损策略。他可能实际上会更频繁地访问其中一个 NVM 集，让它先耗尽。然后他就可以转移到其他的 NVM 集。

Paul：我想补充一点，我觉得你的问题是，为什么我们需要这个额外的抽象层？为什么需要在一个耐力组内部有多个 NVM 集？答案是，也许并不需要。我听过一个人说她有这样一个用例。可能那不是必需的，但我们现在就是这个状况。可预测延迟模式（predictable latency mode）是按 NVM 集来表达的。所以理论上，你可以在一个耐力组内有两个 NVM 集，它们处于不同的工作阶段，但实际上连这个也行不通。所以也许这有点过度设计了。在标准制定中，我们有时为了获得某人的投票而加入一些灵活性。

主讲人：我想说的另一件事是，当我们最初开发 NVM 集时（那是在耐力组概念之前），我们正在开发可预测延迟模式和 NVM 集，我们试图建立一个不强制 NVM 集必须是基于硬件概念的模型。它可以是虚拟化的，也可以是硬件的，我们不想在定义中固化它。但最终，我们需要一种方式将其与硬件、与容量、与磨损均衡联系起来。你要在这些资源上进行磨损均衡，于是我们创建了耐力组。也许如果我们从头开始，只用其中一个概念就够了。而且我会说，我本想像 Paul 那样回答这个问题，我还没在实际应用中看到过在一个耐力组内有多个 NVM 集的例子。通常是一对一的，而且可能一直会是这样。

观众：我的问题与 IO 确定性和耐力组这个概念有关，试图想象 SSD 控制器内部的并行性，以便我们可能获得裸片级别的粒度。话虽如此，你们不觉得这实际上给 FTL 设计带来了更多挑战吗？因为 FTL 实际上并不是在裸片级别工作的，而且数据和元数据并不那么容易分开。所以，除非 FTL 真正地分开了数据和元数据，这个原则上要如何工作呢？

Mark Carlson：FTL 有很多不同的方面，对吧？我们在这里只解决了磨损均衡的问题。我们没有解决垃圾回收、性能或写放大的问题，尽管这些新功能确实有帮助。但是，将部分磨损均衡功能移出驱动器的整个用例在于，我可以通过这种方式在系统层面甚至数据中心层面进行磨损均衡。我现在可以以非常精细的粒度决定我的整个数据中心的磨损将发生在何处。所以这就是用例所在。仅仅是将 FTL 的磨损均衡方面移出驱动器，对这些数据中心级客户来说就是一个巨大的帮助。

Paul：我想指出两点。首先，我们实际上还有七分钟。另一点是，当你使用屏幕上展示的这个模型时，主机必须承担跨越这些耐力组进行磨损均衡的责任。而且主机完全有可能，基本上，用尽并烧坏其中一个耐力组。这将要求修改保修条款来明确这一点。因为我们驱动器供应商，如果我们按你说的做了，我们不希望你回过头来说：“我不明白”。这话有点刻薄，但当你开始以这种模式操作时，这是你需要注意的一点。

主持人：这些回答了你的问题吗？

观众：不完全是。我需要更好地解释我的问题。我想我的问题是，假设我们试图在 FTL 中跨越不同的裸片来构想这些 NVM 集。FTL 中的元数据，也就是逻辑到物理的映射，通常情况下，除非我们把 FTL 分割成八个并行的 NVM 集，我们并不会在 SSD 控制器内运行八个并行的 FTL 线程。所以，这个概念的本质是，对一个 NVM 集的写入不会与进入另一个 NVM 集的 IO 产生交集，对吗？

Mark Carlson：是的，没错。在上面的例子中，你一次性进入一个 NVM 集的最大带宽会略低于四分之一。

观众：但是 FTL 内部的元数据，除非我们创建完全并行的 FTL，我看到在不同 NVM 集之间会发生交集，这是我的…

主讲人：我必须强调，NVMe 是一个接口规范。你如何组织你的 FTL，那是一个实现细节，我们不希望去规定它。这里有创新的空间。而且，关于应该启用多大的灵活性，正在进行一场非常健康的辩论。这在某种程度上是开放通道与更传统的 SSD 实现方式之间争论的本质之一。所以，规范正在启用一些模型，这些模型肯定会产生影响，而且可能效率不高。

观众：我明白了。我认为开放通道更容易，因为 FTL 已经推给了主机。在这里因为…

主讲人：是的，我们在某种程度上试图走中间路线，我们试图让 NVMe 成长以支持这些用例。但我们认为市场会自己找到出路，比如，它会开发出 ZNS 驱动器，也会开发出传统驱动器，还可能开发出一种类似开放通道的驱动器，使用我们正在讨论的用于耐力组管理的 NVMe 接口扩展。我们试图构建的是，让 NVMe 成为一个可以处理所有模型的保护伞，而不是让所有这些都分崩离析。对我来说，ZNS 是一种方式… 想象一个驱动器，整个驱动器只有一个耐久性单元，一个 NVM 集，但我却在使用 ZNS。对我来说，这意味着文件系统负责垃圾回收，而驱动器负责磨损均衡。是的，这是一个非常清晰的划分。我个人就是这么想的。我想大多数早期采用者也是。

观众：现在我的问题是… 我不知道这个问题是否被经常讨论，但是关于目标分区大小、分区容量与内部物理资源的关系，大家的看法是什么？

Mark Carlson：我个人… 去和你的供应商谈。

观众：是的，我会和我的供应商谈的。非常感谢。为了在使用这些东西的方式上获得统一性，我认为至少在模型上需要有一些一致性。也许这可以通过我们中的几个人和我们所有的供应商都去沟通来实现。

Mark Carlson：是的，就是这样。就像 Mark 说的那样，我认为没问题。

观众：关于开放通道的一个抱怨是它每 TB 驱动器存储所使用的 RAM 数量。我们在主机上每 TB 存储大约需要使用多少 RAM ？

主讲人：David，你想回答这个问题吗？我给出的答案是，这取决于你如何构建系统。如果你决定在上一层重新实现 FTL，这个问题就可以回答。他们展示了很多其他模型，你的情况会有所不同。

观众：那么最坏和最好的情况是什么呢？你需要一个数字。

主讲人：答案是“视情况而定”（it depends）。你不会得到更具体的答案了。现在要明确地回答这个问题还为时过早。

David Black：David Black，我站起来其实是想给 Paul 点赞，因为他提到了耐力组的一个这里没提到的用途。耐力组做的一件事是，它将 IO 统计信息与介质而不是控制器绑定在一起。而台上的 Suler 先生在耐力组日志页上做了所有繁重的工作才使之成为可能。谢谢。

观众：最后一个问题。我们以前有流（streams），现在我们有了 NVMe 命名空间。流（streams）是不是已经死了？

主讲人：抱歉，Dave，你说了什么？你在向座谈小组征求政治意见吗？

观众：不，我说的是规范。我说的是下一版规范。

主讲人：我们没有弃用它们，也没有计划弃用它们。它们会继续被使用吗？我们得再看看。我不知道。还有人需要流吗？好吧，这就是你的答案。没有。谢谢各位的到来。