关于这个主题还有许多其他问题，但大多数问题与格式化分区或驱动器故障有关。就我而言：
在 Gparted 中调整和移动 2.7TB 分区时，我遇到了一个错误，导致整个程序冻结。（我没有屏幕截图或输出，就我记得的而言，这是关于读取分区时的错误）。
我运行了mkfs.ext4 -S。fsck.ext4 -y花
了几天时间，然后系统崩溃了，因为它用完了 RAM 和 SWAP（8+8GB）。在添加了 200GB 的交换空间后，fsck运行了大约两周，但突然因错误而停止，不幸的是我没有截图。
mkfs我尝试再次运行相同的组合fsck，但每次fsck运行时，它都会使我的 CPU 的两个核心达到 100%，并彻底冻结整个系统。甚至不起作用alt+sysrq REISUB。这种情况发生了 2-3 次。
当前输出fsck为：
ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device>
运行时sudo e2fsck -b 8193 or 32768，输出为：
e2fsck: Attempt to read block from filesystem resulted in short read while >trying to open /dev/sdd1 Could this be a zero-length partition?
我尝试运行testdisk，但它停在 2026 柱面，无论我等待多久都不会再继续。我确实有一个由 制作的备份ddrescue，但因此我的所有驱动器上的可用空间都完全用完了。
我担心，移动/调整分区大小期间出现的错误会导致分区上的所有数据被切碎并且数据恢复软件无法理解。
我将非常感激任何关于我下一步该怎么做的建议。
我是否应该放弃并将dd图像放回分区并重试fsck？
谢谢
答案1
您是否知道在移动分区时或调整分区大小时原始调整大小/移动是否失败？
如果是在移动过程中，那么一个好方法是恢复 dd 映像并尝试找出扇区重复的位置以及扇区重复（或复制）停止的位置。从那里，您可以反向工作以将分区的两半拼凑在一起。
如果问题发生在调整大小操作期间，并且 fsck 等工具无法解决问题，那么您可以考虑尝试使用磁盘扫描工具恢复数据文件，例如照相记录。