我尝试使用 GParted 缩小分区。显然，这是一个巨大的错误，因为它不知何故决定缩小然后移动。压缩花了一个小时，估计移动需要 9 个小时，我猜是右边的几兆字节*。
数据并不是极其关键的，但我知道的足以让我了解我对文件系统知之甚少。我天真地认为，因为它“只是向右移动”，所以我可能会损坏 GParted 移动位置的文件，但我不认为我会损坏整个文件系统。好吧，也许它会损坏整个文件系统，但我认为它是可以恢复的？
然而这个答案说“请注意：不要中断 GParted！这样做很可能会损坏您的分区表或其他重要的磁盘部分。”这让我很担心。也许移动文件系统并不是简单的“把那边的位拿过来放在这里”，而是一点一点地从内存的一端移动到另一端。
这个问题的答案对我来说可能毫无用处，因为我决定不取消该操作。GParted 的消息“现在停止将破坏文件系统，如果您确定 [原文如此]，请再次中断”当然的那个。
但我很好奇，如果我再次遇到这个问题，我可以/应该做什么。如果我看到 GParted 想要做两件事，我会估计什么时候可以在两个操作之间强制退出（我相信这是可能的，在实际要求 GParted 执行之前仔细检查 GParted 想要做什么……）。因为在看到“向右移动并缩小它”未能取消任何事情。
我认为我parted将来会使用它，因为我之前用过一次，它是我遇到的最用户友好的命令行应用程序之一。因为在 parted 中，显然你可以取消待处理的操作而不取消当前正在运行的操作，而 GParted 中没有实现此功能. 至少不是 Rescuezilla 打包的版本。
TL;DR：我不想等待 GParted 移动文件系统。如何中断 GParted 并恢复最多的数据？请不要回答“使用<文件恢复软件>”。
* 这句话可能会让人困惑。我正在移动 1+TiB 的数据，我对它花费这么长时间并不感到意外。当我说几兆字节时，我的意思是我认为 GParted 实际上移动了这么远的数据。
答案1
我尝试使用 GParted 缩小分区。显然，这是一个巨大的错误，因为它不知何故决定先缩小然后移动。缩小分区花了一个小时，估计移动分区需要 9 个小时，我猜是右边的几兆字节*。
文件系统使用从分区开头开始的偏移量来跟踪所有数据和元数据的位置，因此调整大小工具通常被编写为始终从末尾收缩（这样，它们只重新定位当前在要切碎的范围内的数据，其他一切都保持不变），并且不支持从开头收缩。
数据并不是非常重要，但我知道的足以让我了解我对文件系统知之甚少。我天真地认为，因为它“只是向右移动”，所以我可能会损坏 GParted 移动位置的文件，但我不认为我会损坏整个文件系统。
在此阶段，它不是移动单个文件，而是将整个文件系统作为一个巨大的数据块移动。有点像这样：
在 GParted 执行移动期间，文件系统本身“不知道”移动正在发生：其元数据不是每当文件的某些部分被重新定位时都会更新（因为移动过程甚至不关心它是否正在移动文件系统，并且因为在最后，当“开始”位置最终被移动时，所有这些元数据更新都必须撤消）。
因此，如果你中途中断移动，就会出现以下情况全部位于“已移动”部分（橙色）的文件（和元数据）现在实际上存储在文件系统认为它们存储位置的偏移处。（例如，如果移动了 +1 GB，那么之前位于 100~101 GB 的文件范围现在位于 101~102 GB，但文件系统不知道这一点。）
嗯，也许它会破坏整个文件系统，但我认为它是可以恢复的？
实际上，只有从中断的位置继续移动过程才可以恢复。（有些工具可以做到这一点，但 GParted 不能。）
TL;DR：我不想等待 GParted 移动文件系统。如何中断 GParted 并恢复最多的数据？
如果你知道移动被打断的确切位置，那么理论上可以通过设置设备映射器“dm-linear”将两个分割部分合并为一个虚拟设备，使其工作方式与原始分区相同，从而实现恢复。（我认为这就是 LVM2 的pvmove底层实现方式。）然后可以挂载文件系统并将所有数据从中复制出来。
或者，可以使用工具来移动块后退回到其原始位置，让你回到开始的位置。（我不知道是否存在，但写起来不会花很长时间。）
如果不知道分裂的位置，几乎就无法恢复。（嗯，它可能可以猜到，因为“间隙”仍然包含刚刚“移出”的旧数据副本，但我不敢打赌。）
答案2
我的建议是不要中断 GParted——关于那些有意或无意取消它的人，有太多悲惨的故事了。
让它自行运行，除非您有磁盘的备份映像，您可以使用它将其恢复到启动 GParted 之前的状态。
拥有良好的备份并且不介意磁盘丢失是停止 GParted 的唯一安全方法，但即使这样也不值得麻烦，因为恢复磁盘所花的时间与等待 GParted 一样多。
下次，也许使用另一个更易于中断的分区编辑器。
答案3
GParted 的 GUI 取消按钮具有内置的回滚功能。
它将取消分区移动，然后撤销已经执行的操作。
我取消了 8 次缩减和移动操作中的 30 分钟（1.5 TB 数据），花了 30 分钟撤消（如预期的那样），然后只进行了一次花费大约 3 小时的移动，现在运行正常。