LWN：FDP——更加自由的数据放置！

关注了就能看到更多这么棒的文章哦～

Flexible data placement

By Jake Edge
May 2, 2025
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/1018642/

在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM+BPF）上，Kanchan Joshi 和 Keith Busch 共同主持了一个存储和文件系统分会，讨论了数据放置（data placement）的问题。数据放置是指数据在存储设备上实际写入的方式。讨论回顾了之前峰会上的议题，核心思想是向企业级固态硬盘（SSD）提供提示（hint），以帮助它们在数据存储位置上做出更优决策；关于提示最近一次讨论是在 2023 年的峰会。如果 SSD 能够将生命周期相似的数据分组存储，可以延长设备寿命，但这需要进一步完善细节。

Joshi 首先指出，宿主机系统提供的逻辑放置（logical placement）与数据在设备上的物理放置（physical placement）不同。他说，决定数据放置的位置是一个问题；如果存在一个数据创建者，以及数据创建者与设备之间的多个层（例如，filesystem，即文件系统、device mapper，即设备映射器），那么最终决定数据去向的是最接近设备的那一层。目前，数据通常是顺序写入的，因为设备上在每一个处于 open 状态的 erase block（擦除块）只有唯一一个 append point（追加点）。

弹性数据放置（Flexible Data Placement，FDP）是一项 NVMe SSD 特性，它允许对写入操作打上标签（tag），以指示这些写入是否应该被分组。支持 FDP 的 SSD 可以拥有多个 append point，分布在不同的 erase block 中，从而根据数据的 tag 对其进行分组。然而，写入未标记数据或使用无效 tag 并不会导致错误。谁应该决定应用哪些 tag，是应用程序还是 filesystem 等中间层，这是一个悬而未决的问题；Joshi 说，设备本身并不在意，但如果数据被标记了，它就“可以按最初的意图进行分组”。

Busch 说，SSD 通常拥有丰富的资源来并行处理任务，但“没有任何提示，它就不知道应该如何区分”。提示将允许多个应用程序在不共享资源的情况下进行写入。这些提示还将有助于减少 write amplification（写入放大），因为生命周期相同的数据可以被放置在一起（并一起更新或擦除）。

Josef Bacik 说，他知道 Busch 使用 Btrfs 进行了一些实验，将数据写入与 metadata（元数据）写入分开分组，但性能提升并不显著。Busch 表示同意，并指出仅仅将数据与 metadata 分开还不够精细。例如，如果能将 B-tree（B 树）写入与 journal（日志）写入分开，效果会更好。

Bacik 建议，他可以根据写入操作的 subvolume ID 来打 tag，这可能会有所改善。Busch 说，根据具有相似写入到丢弃（或覆盖）时间特性的操作对数据进行分组，并为其提供不同的 tag，将会产生影响。Bacik 询问了可用的 tag 值数量。Busch 说 tag 是 16 位，但目前的硬件并未全部利用；范围从 8 个 tag 到几百个 tag 不等。根据 tag 的分配方式，存在用完 tag 的可能性。

Bacik 问，filesystem 开发者是否应该直接开始使用这个特性，并寄希望于它有所帮助。Busch 说，之前这类工作的不足之处在于缺乏反馈机制，但当前的协议确实提供了获取 SSD endurance measure 的方法，这允许运行实验来查看 tagging 是否有帮助。他说，提供的数字衡量了一个 workload 的 write amplification；报告了写入到设备的字节数以及将这些字节写入到介质上实际需要写入的数据量。测试可能应该在两个系统上使用相同的 workload 进行，一个不使用 tagging，一个使用某种 tagging 方案。

Busch 说，Meta 公司（Busch 和 Bacik 都工作于此）购买的所有 SSD 都支持 FDP，尽管它默认未启用。为一块新硬盘配置 FDP 需要几分钟时间。所有主要供应商都支持这项特性，但每家实现方式略有不同，因此提升效果会因 SSD 类型而异。

Chris Mason 问，是否对其他带有 journal 的 filesystem，例如 ext4 或 XFS，进行过测试。“有些 filesystem 的某些重度使用部分在 SSD 上的生命周期非常特定，而 Btrfs 不属于这类。”Busch 说，filesystem 测试并不算广泛；重点转移到了应用程序上，但他同意，对这些 filesystem 的 journal 写入进行 tagging 可能会产生很大影响。

Ted Ts'o 说，很久以前进行过一些测试，也许是 Martin Petersen 做的，会将特定类型存储设备的 database log（数据库日志）写入或 filesystem journal 写入分开。结果令人鼓舞，但那些存储设备昂贵且难以获取，这意味着开发者没有太多机会进行实验。

Petersen 说，对于已知 workload 在特定 SSD 型号上、应用程序或 filesystem 能够添加 tag 的用例，FDP 模型是好的。“但这对于所有其他用例来说并不是一个好模型。”早期提示尝试失败的原因也存在于 FDP 中：例如，有八个 tag 需要某种方式在设备上的各个 filesystem 之间分配。问题在于 tag 值是一种稀缺资源。如果它们不稀缺，事情就可以总是根据数据应该如何分组来打 tag，但 FDP 和早期的机制不够通用；每个驱动器、filesystem 和应用程序的组合都必须单独测试才能知道哪种方式有效。

Zach Brown 说，他很高兴看到 FDP 设备提供的可见性增加；“我们太习惯于设备是糟糕的黑盒（shitty black boxes）了”。Busch 表示同意，并指出缺乏反馈很可能是导致早期提示尝试失败的部分原因。

Busch 说，当前的 patch 尚未将 FDP 特性完全整合到系统其余部分中。取而代之的是一个 passthrough 接口，允许 user space（用户空间）直接向 NVMe device 发送命令，“这样你就可以完全控制了”。它在 sysfs 中将可用的 tag 数量暴露为 max_write_streams 。他说，“这个 passthrough 接口用起来并不特别愉快”。NVMe 命令必须在 user space 中构建，这不是正确的抽象层次。因此，io_uring 有一个新的 write-stream 命令，提供了一种更好的方式来访问该特性。它仅适用于 direct I/O（直接 I/O），并且他质疑将其连接到 buffered I/O（缓冲 I/O）是否有什么意义。

Joshi 说，通过 iomap 接口将 FDP 连接到 filesystem I/O 仍然是一个未解决的问题。他说，有这方面的计划，需要进一步讨论。一旦一个 filesystem 被挂载，它将拥有 block device（块设备），因此会看到并能够管理所有的 write stream（tag）。一个 filesystem 可以支持应用程序管理的 write stream，根据其规则映射到硬件 tag，或者它可以直接自己管理 stream。这两种模式可能并非互斥，因此一个 filesystem 可以选择支持混合模式。

他说，即使仅仅是应用程序管理的情况，也需要一个新的 user interface 以及 per-filesystem 的启用。此外，是否存在一个通用的 write stream 应用程序管理代码也是一个问题，这样每个 filesystem 就不需要实现自己的代码了。

Stephen Bates 问，write stream 是 per-NVMe-namespace 的还是全局的。Busch 说，它们是全局的，但 tag 值的一些子集可以专门分配给一个 NVMe-namespace。

Busch 说，他原本希望使用现有的 write-hints 接口来支持 FDP，该接口目前是一个无操作（no-op）。Christoph Hellwig 说，filesystem 仍然应该参与进来，以便正确映射应用程序提供的 tag 值。Busch 说，这需要在 filesystem 中做大量工作，而 write-hints 选项则不需要；filesystem 参与进来会更好，但将其留给应用程序则是一条更简单的途径，也能获得部分好处。

Bacik 宁愿不让 Btrfs 等 filesystem 作为 tag 的仲裁者（arbiter），但 filesystem 可能也想使用这些 tag。Busch 说，如果 filesystem 是仲裁者，它们可以为自己保留一部分 tag 空间，但这甚至可能导致与安装在其他 partition（分区）上的 filesystem 发生 tag 冲突。因此，Bacik 希望由 block layer（块层）来仲裁。

Petersen 说，过去进行过一些实验，filesystem 会根据属性（例如 journal 写入对比 random writes，即随机写入）来标记写入。添加了一个 scheduler（调度器）来完成 filesystem tag 到硬件 stream 的映射。“它有效。虽然不漂亮，但它具有灵活的优势，因为你可以更改那个 scheduler 来匹配你的应用程序 workload。”现在，开发者可以使用一个 BPF program 作为 scheduler 来做类似的事情，并针对 workload 进行调优。

他抱怨应用程序驱动的提示（hints）之一是，kernel 已经拥有它所需的知识。应用程序不应该告诉 kernel 这些写入是针对某个应用程序并指向某个特定文件——“我们知道这些，我们就是 kernel”。user interface 不应该绑定到硬件；“在 kernel 中，我们可以调度资源，这就是我们存在的原因。”

然而，Javier González 说，有些应用程序可以在单个文件内使用多个 stream。Joshi 表示同意，并说 filesystem 和 block layer 不一定能对 write stream 的分配做出最佳决策。Bacik 说，他不希望 filesystem 阻碍应用程序做它们需要做的事情。

Ts'o 说，可用的 stream 数量少使得事情变得困难；他说，假设有无限数量的 stream，那么可以将 inode number（inode 号）用作 tag，“然后让 block layer 处理一切”。既然情况并非如此，就需要有东西来分配 stream，这可能意味着拒绝一些请求；当然，每个应用程序都会声称它的文件是最重要的。

会议结束时有点混乱，出现了多个支线对话，导致难以跟进，也许是因为会议持续到了随后的休息时间。讨论转向了衡量系统 tagging 数据效果（好或差）的方法。Busch 说，可以使用的测量指标是来自硬盘的 write amplification 信息以及 p99 latency（p99 延迟），当生命周期相似的数据得到正确分组时，这两者都应该会降低。Joshi 通过简要回顾一篇关于 FDP 的最新论文中的部分结果，结束了本次会议。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～