为什么 resize2fs 通过首先移动指定范围末尾之后的块来缩小分区?这可以改变吗?

为什么 resize2fs 通过首先移动指定范围末尾之后的块来缩小分区?这可以改变吗?

我目前正在缩小一个相当大的分区,resize2fs以恢复 LVM 卷组中的空白空间。

按照我的理解,文件系统收缩操作对于(文件系统中的最后一个块)和(操作完成后应该是最后一个块)之间的每个块执行以下操作:

  1. 检查是否被任何文件使用
  2. 如果是,则将该块以及该文件使用的所有块复制到它们适合的分区中的最早位置
  3. 更新元数据,以便该文件块的记录现在指向块的新位置

这些步骤似乎并不依赖于命令在其中处理这些块——您可以开始在任一端移动块,并且无论哪种方式都可以工作。然而,在这样的情况下:

+---------------------------+--------------------------------------------+
|    resize target          |      space to move blocks away from        |
|                           |                                            |
+-----------+---------------+---------+------+---------------+-----+-----+
|   used    |                         |  to  |               | to  |     |
|  space at |                         | move |               | move|     |
|   start   |                         | (1)  |               | (2) |     |
+-----------+-------------------------+------+---------------+-----+-----+

...resize2fs将首先移动 (1),然后移动 (2)。

这是为什么?对我来说,首先执行(2)的优点是,如果用户认为完成调整大小操作需要太长时间,并且他们中途停止,那么就会取得一些进展,并且如果他们选择用更大的目标尺寸(更小的收缩)再次尝试,那么下一次要做的事情就会更少。

就我而言,只要我可以缩小 LVM 卷并使用备用 LVM 范围,我就可以部分调整大小,但要做到这一点需要释放文件系统末尾的空间,所以我一直在重复运行该resize2fs命令并以小增量手动缩小卷。有一个更好的方法吗?

这个问题类似,它是关于如何从另一个方向恢复文件系统空间——在开始分区的,而不是结束的。

相关内容