我试图缩小我的家庭分区。为此，我关注了这篇ArchWiki文章。据此，我首先使用调整了文件系统的resize2fs大小，然后使用调整了物理设备的大小parted。在resize2fs参数中，我给出了我想要的大小，为XG，并在调整大小后报告它的新大小为Y（4k个块）。根据此信息，我计算出我的分区大小为（Y * 4）KiB，当使用parted调整物理分区大小时，我使用了该大小。但实际上，它是（Y * 4）KB。因此，现在文件系统的总块数高于物理设备的总块数。
在resize2fs手册页中指出，如果未指定大小，它将占用设备的整个空间。因此，为解决此问题，我resize2fs再次运行以使fs大小与物理大小匹配。但是它给出了以下错误：
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>?
有什么办法可以恢复吗？安装和访问该分区是否安全，以便可以进行备份？
谢谢！
从您写的内容来看，您意外缩小了一个小于其所包含文件系统的分区。它本身不会丢失任何数据，但此后您可能会执行的几乎所有操作都可以[具有]。这肯定包括resize2fs，e2fsck和mount。您似乎很幸运，因为您执行的两个命令都检测到了问题并中止了。
最大的问题是，您是否通过缩小分区来创建额外的空间来做任何事情？如果这样做，那么如果创建了另一个分区并对其进行了格式化，则可能已损坏了数据，无法修复。如果没有，那你可能还好。
要解决当前的问题，您必须使用诸如parted将分区增加到其原始大小的工具。如果您已经没有任何可用空间，那么您的数据应该就在您离开数据的地方。这将解决当前的问题，您可以使用e2fsck再次检查。如果它给您的警告与第一次相似，请中止。
问题的根本原因是resize2fs 在使用收缩分区之前，您没有正确收缩文件系统parted。这是将所有文件数据移出要从分区中删除的空间所必需的。
我注意到您正确引用的Wiki指示您应该在resize2fs...中指定大小。
...请注意单位，并花点时间了解您输入的数字。ext2 / 3/4中的4k块表示4096个字节。在其他地方，“阻止”一词可能意味着完全不同的含义。还有许多分区程序，包括parted区分KB，MB ...和KiB，MiB。确保您知道要使用的单位：
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句