LWN：改变文件系统resize方式！

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

Changing filesystem resize patterns

By Jake Edge
May 11, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894629/

在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）的文件系统会议上，Ted Ts'o 提出了文件系统经常需要调整 size，以及是否应该因此来相应地改变文件系统创建时的默认参数。这源于他与 XFS 开发者 Darrick Wong 的一次谈话，Wong 遇到 ext4 里也有人碰到的类似问题。他简要介绍了这个问题以及它是如何产生的，然后引导大家讨论如何解决这个问题。

Problems

Linux 文件系统通常被设计成支持调整大小的（resize），但当时的规划是一开始就是一个相当大的文件系统，然后定期添加一些大块空间（big chunks）。文件系统数据结构的大小和创建都是基于正在创建的文件系统的大小。他举了一个例子，使用 md-raid 的 RAID 阵列来构建出一个新磁盘，然后 resize 调整文件系统大小从而完整地使用这个磁盘。新的磁盘可能是现有文件系统 size 中的很大一部分了，但文件系统本身已经相当大了。

[Ted Ts'o]

另一个用例是在一些 NAS(network-attached storage)项目中，它们想创建一个 100MB 的文件系统，用 dd 命令来安装上来，然后对它 resize 进行扩展，比如扩展到 10TB。Ts'o 说，当时只有几个这样做的项目，所以 Linux 文件系统的开发者能够 "猛烈地抨击他们，盯着他们选择正确的做法"，来创建更大的文件系统来符合预期 size。但是，目前在云上也出现了类似的普遍需求。

云服务供应商通常有规定最小的虚拟块设备（virtual block-device）size ，比如说 10GB，然后用这个 size 来创建文件系统，接下来会基于这个来调整 size，比如把 10GB 的文件系统可能被扩展到几十 TB。他说，与 NAS 项目的差异在于，目前有了更多的云计算供应商，而且其中许多法是相当天真的。他们使用 mkfs 的默认参数，这些参数是针对 U 盘的，针对这种 size 巨大的文件系统可能会导致出现无法正常工作的情况。

此外，许多云服务厂商会根据正在使用的虚拟块设备的 size 来向客户收费，这意味着客户也有充分动机来等到文件系统快满时才会 resize 进行扩大。有一个常见的模式是，一旦一个文件系统已经使用了比如说 99%的容量，那么就会再增加 1GB 或 5GB。文件系统中不断重复这种做法。"这往往会导致文件系统碎片化达到最坏情况。" 他说，大多数文件系统的设计并不是为了在几乎满负荷运行时也能很好地工作的。

Possible solutions

虽然问题已经被发现，但尚未有解决方案。他希望听听与会者是否有一些好主意。Ts'o 说，有一个做法会很有用，那就是为大型文件系统镜像文件来制定一种标准格式专用于今后占用全部 block device 空间的情况。ext4 的开发者一直在尝试使用 qcow 格式；在 e2fsprogs 中有一个叫做 e2image 的工具可以创建这种映像文件，它们只包含文件系统所实际使用的 block，所以它们比起所创建的文件系统实际上小得多。XFS 的开发者也一直在关注 xfsdump，它有一些类似的功能，但是是针对 XFS 文件系统的。

在他和 Wong 讨论时，他们都赞同使用单一标准格式（single standard format）会很有用。他说，有一种可能方案就是 qcow，但它没有很好地规范定义下来，而且创建 qcow 格式的 QEMU 开发者不鼓励将其作为 interchange format 来使用。也许还有其他一些可行方法，但是我们必须要在各种文件系统之间达成一致。这将有助于摆脱之前那种 "dd 是传输文件系统的最先进工具" 的观点。

另一种可能性就是改变 mkfs，使其 "有时或总是" 创建能够适合扩展到巨大 size 的文件系统。这只需要简单地改变默认值就可以实现，例如，可以哪怕是在 U 盘上也总是创建一个巨大的 journal 日志。Amir Goldstein 说，这样做效果并不好，因为这些小设备中的很大一部分空间会被对它们没有用处的 journal 所消耗。Ts'o 说，这可能不是最佳解决方案，但这是一个可以实现的方案。

Ts'o 说，也许 block device 块设备可以给 mkfs 一些提示信息，来表明它今后有可能会给这个文件系统未来增加 size 的时候提供空间。这些提示信息可以直接宣布这个设备根本不能 resize，比如 U 盘这种情况；也可以宣布说它是被安装在云服务中的一些虚拟块设备里，也就是今后很可能需要扩展空间。这样一来，U盘的默认值就可以继续保持使用，但相关参数就能切换到更适合云计算的情况。可以准备一套基于设备名字的启发式方法，来试图确认它今后是否有可能会增长。如果块设备提供了这个提示信息，这就把责任推给了设备驱动程序，但该代码确实是有能力知道更多的关于底层存储设备情况的信息的。然而，这些都不是一个完美的解决方案。

他还指出，提供提示并不能解决那些试图将存储成本降到最低的客户的问题，因为每当文件系统填满时，就会增加少量的存储空间。他说，这种文件系统的性能会严重下降，以至于客户为额外计算能力所支付的费用可能比他们节省的存储费用还要多。据他所知，除了对客户进行教育外，没有其他什么解决方案了，而客户的数量远远超过了文件系统开发者的数量，所以教育好他们也是不现实的。

Goldstein 问，创建可能会扩展的文件系统的那些人是否会使用 mkfs 的选项来将产生的文件系统放到一个文件中，这也许可以是个机会来提醒他应该换一组更合适的参数。Ts'o 说，NAS 的开发者一直都在询问这个问题，所以文件系统的开发者能够给他们一套参数并且有效地满足他们的要求。然而，这对云计算的情况并不适用，因为虚拟块设备看起来很像是普通的 SCSI 设备。使用基于设备名的启发式方法，或者也许是基于一些现在没有人设置的 "神奇的 SCSI 属性" 可能是一种识别云服务场景的可行方法。

Josef Bacik 说，blkid 大多数信息没有什么用，但其中磁盘的型号名称也许可以被解析来确定它是否是一个云设备。他猜测，在一个特定的云服务之中，云提供商应该会统一使用一套名称。Ts'o 同意这一点，并认为结果应该 encode 之后也加入 blkid 中，这样就不必每次都重新分析了。Bacik 认为这很有意义，这样文件系统的开发者就可以依赖一个跟设备类型相关的单一信源了。

Chris Mason 想知道是否有统计数据表明人们会不会经常在云上创建小文件系统并且永远保持小文件系统。他担心仅仅根据设备是否属于云类型来做决定，会对那些一直使用小型云文件系统的用户造成损失。Ts'o 说，他没有这方面的统计数据。他通常听到的信息是客户不断给他们的文件系统添加 1GB 大小的 chunk 进来，然后抱怨性能不好。

Ts'o 说，问题的一部分在于文件系统没有得到关于设备最大 size 的信息；每个云提供商都有自己的最小、最大和增量 size。比如说可以给 mkfs 添加参数来让用户指定最大 size，但大多数用户不会知道这些选项。用户通常使用发行版安装程序或默认云服务映像文件，所以没有机会让他们指定这些信息。

Goldstein 问：是否有可能调整文件系统的底层部分的 size，比如 journal 的 size，这样问题就会减少？Ts'o 说，这取决于文件系统；ext4 可以调整其日志的大小，因为它允许日志不连续，但他认为 XFS 是需要一个连续的日志空间的。不幸的是，没有一个 XFS 的开发者能够在现场参加 LSFMM，但 Eric Sandeen 利用 Zoom 聊天指出，需要调整的不仅仅是日志。Mason 还指出，在文件系统中，有很多数据结构都需要随着文件系统 size 而改变。

Bacik 说，房间里的每个人都很清楚，"为用户创造更多的选择，只会导致今后有更多的可能性出现问题"。最好的方式就是让工具默认配置为智能的方式。他们可以从 blkid 以及其他地方来收集信息，以做出工具所能做出的最佳选择。Ts'o 说，工具不会总是做出正确的决定，也许可以为高级用户增加一些选项。

大家讨论了为了让文件系统对 size 的增加更有弹性而可以做的一些事情。Ts'o 列举了 ext4 可以做的几件事，比如默认情况下将 block size 改为 4KB，并自动调整 journal 的大小；Sandeen 提到，XFS 也许应该使有大量分配组（allocation groups）的文件系统变得更有效率，来作为部分解决方案。这些都是针对文件系统的，Ts'o 说他希望能找到方法来更普遍地解决这些问题。然而，会议的时间已经用完，暂时还没有看到真正的解决方案。

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

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