我ext4用以下命令缩小了文件系统resize2fs：
resize2fs -p /dev/sdn1 3500G
（FS 用于 2.3 TB）
然后我用parted调整了分区大小，并在设置新的结束时留下了0.3%的余量（~10 GB）：
(parted) resizepart 1 3681027097kb
最终，事实证明这太紧了：
# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
The filesystem size (according to the superblock) is 917504000 blocks
The physical size of the device is 898688000 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
然后我再次调整分区大小，这次的边距为 3%：
(parted) resizepart 1 3681027097kb
之后，文件系统检查通过：
# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdn1: 278040/114688000 files (12.4% non-contiguous), 608536948/917504000 blocks
我已经partprobe /dev/sdn按照这两个resizepart命令运行了。
我在整个过程中都没有安装文件系统（甚至还没有安装）。
我将分区大小调整为太小的值的中间步骤是否会损坏文件系统？
成功运行是否e2fsck足以确保数据没有被损坏？
答案1
我将分区大小调整为太小的值是否损坏了文件系统？
在你的情况下这是不可能的，特别是因为你足够好心阻止了那个fs(c)杀手，但你不能完全排除这种可能性。
例如，当它是 msdos 分区表的扩展分区内的逻辑分区时，就会发生损坏。逻辑分区是链表，因此逻辑分区之间有一个扇区用于指向链表中的下一个分区。如果缩小/调整此类逻辑分区的大小，则磁盘中间某处的某个扇区（部分）会被覆盖。
另外，一些分区程序可能喜欢将事情归零。 LVM 也是如此，在每个 lvcreate 上，它都会像创建的 LV 的前 4K 一样清零，此外，不能保证反转拙劣的 lvresize 会给您带来之前使用的相同范围。如果运气不好，LV 可能位于其他物理位置，这就是为什么您只能通过lvresize 之前创建的内容vgcfgrestore来撤消此类事故。/etc/lvm/{backup,archive}/
对于 SSD，存在一种 TRIM 时尚，它会导致各种程序向 SSD 发出未经授权的 TRIM 命令。 LVM 在 lvm.conf 中执行此操作issue_discards=1（始终将其设置为 0），希望各种分区程序永远不会采用此行为。
成功运行 e2fsck 是否足以确定数据没有损坏？
大多数文件系统无法检测其自身元数据之外的数据损坏。这通常不是问题，因为你不应该表演这样的特技。如果您有备份，您可以将文件时间戳/校验和与备份中的内容进行比较。
我在整个过程中都没有安装文件系统（甚至还没有安装）。
您可以将其挂载为只读，如下所示：
mount -o loop,ro /dev/sdn1 /mnt/somewhere
然后查看文件。
告诉loop,romount 创建一个只读循环设备并安装它。令人惊讶的是，ro它本身并不能保证某些文件系统（包括ext4. （对于像 一样的多设备文件系统btrfs，loop,ro也不会，因为它只影响一台设备，而不是所有设备）。