我试图缩小我的家庭分区。我跟着这个 ArchWiki文章为此。根据这个，我首先使用调整我的文件系统的大小resize2fs，然后使用调整我的物理设备的大小parted。在resize2fs参数中，我将预期的尺寸指定为XG调整大小后，它报告新的大小是Y（4k 块）。根据此信息，我计算出我的分区大小是(Y * 4) KiB当使用parted调整物理分区大小时，我使用了这个大小。但现实却是这样(Y * 4) KB。所以现在文件系统的总块数高于物理设备的总块数。
在resize2fs手册页中指出，如果未指定大小，它将占用设备的整个空间。因此，为了解决这个问题，我resize2fs再次运行，使其将文件系统大小与物理大小相匹配。但它给出了以下错误：
resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/sda3 to 159907584 (4k) blocks.
resize2fs: Can't read a block bitmap while trying to resize /dev/sda3
Please run 'e2fsck -fy /dev/sda3' to fix the filesystem
after the aborted resize operation.
但当我发出它时，e2fsck它报告了不匹配并建议中止。所以，现在我陷入了一个循环：
e2fsck 1.45.6 (20-Mar-2020)
The filesystem size (according to the superblock) is 186122240 blocks
The physical size of the device is 159907584 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>?
有什么办法可以恢复吗？挂载和访问分区以便我进行备份是否安全？
谢谢！
答案1
根据您所写的内容，您意外地将分区缩小到小于其包含的文件系统。就其本身而言，这不应丢失任何数据，但此后您可能执行的几乎所有操作都可能会丢失。这肯定包括resize2fs,e2fsck和mount。看来您非常幸运，因为您执行的两个命令都检测到了问题并中止。
最大的问题是，您是否对通过缩小分区创建的额外空间做了任何处理？如果你这样做了，如果你做了一个额外的分区并格式化它，那么您的数据可能已损坏且无法修复。如果没有，那么你可能没事。
要解决当前问题，您必须使用诸如parted将分区恢复到原始大小之类的工具。如果您已经对可用空间没有执行任何操作，那么您的数据应该位于您离开的位置。这将解决眼前的问题，您可以用来e2fsck仔细检查。 中止如果它给你一个与第一次类似的警告。
问题的根本原因是您没有正确缩小文件系统resize2fs 前您使用 缩小分区parted。这对于将任何文件数据移出要从分区中删除的空间是必要的。
我注意到维基百科resize2fs您引用正确表明您应该在...中指定尺寸。
...请非常小心单位，并花时间理解您输入的数字。 ext2/3/4 中的 4k 块意味着 4096 字节。在其他地方，术语“块”可能意味着完全不同的东西。许多分区程序还parted区分 KB、MB...和 KiB、MiB。确保您知道您想要哪些单位：
- KB = 1,000 MB = 1,000,000
- KiB = 1,024 MiB = 1,048,576