兄弟，这种慢到离谱的分区resize确实让人崩溃，尤其是等了24小时还在慢悠悠跑的情况，我之前也碰到过类似的糟心事，给你整理几个可以排查的方向和可能的解决思路：

• 优先排查磁盘硬件状态：
  这种极低的读写速度首先要排除硬件层面的问题。你可以用命令 smartctl -a /dev/your_disk（把 your_disk 换成实际的磁盘设备名，比如 sda）检查磁盘的SMART健康状态，重点看有没有坏道、重新分配扇区计数、待映射扇区计数这些异常指标。另外，也可以做个简单的读写测试验证：比如 dd if=/dev/zero of=/tmp/test_file bs=1G count=1（如果是外接磁盘，就写到对应空闲分区，但一定要注意不要覆盖重要数据），看看正常情况下磁盘的读写速度是不是也这么低。如果是的话，大概率是磁盘本身故障、或者连接方式有问题（比如USB3.0设备插在了USB2.0接口上，SATA线缆松动等）。

• 查看resize2fs的具体运行状态：
  GParted的界面可能只显示模糊的进度，你可以直接跟踪resize2fs的进程。先用 ps aux | grep resize2fs 找到它的PID，然后用 strace -p <PID> 看看它正在执行什么系统调用，是不是卡在了某个特定步骤上。另外，ext4分区的原地resize需要先整理碎片、移动数据，哪怕已用空间只有1.5TB，如果分区内文件碎片率很高，也会大幅拖慢速度——不过注意，resize过程中绝对不要随意中断进程，不然可能导致分区损坏，要是之后能顺利完成，你可以用 e4defrag /dev/your_partition 检查碎片情况。

• 考虑中断后的替代方案（务必先备份数据！）：
  如果实在耗不起时间，而且已经做好了数据备份（这一步非常关键！），可以考虑中断resize2fs进程，换一种更高效的方式：先把原分区里的所有数据完整拷贝到另一个磁盘，然后删除原4TB分区，重新创建3TB的ext4分区，最后把数据拷回去。这种方式虽然需要额外的存储空间，但通常比原地resize快很多，尤其是当磁盘存在碎片或者硬件性能一般的时候。

• 检查系统资源是否拖后腿：
  虽然iotop显示resize2fs是主要负载，但还是要确认系统的CPU、内存有没有被其他进程占用。用 top 或者 htop 看看内存使用率，如果内存不足导致大量swap交换，也会严重拖慢磁盘操作速度。另外，Ubuntu22.04的内核有没有已知的ext4 resize相关bug？不过在resize过程中更新内核不太现实，只能事后考虑升级内核来避免后续出现类似问题。

备注：内容来源于stack exchange，提问作者mikemtnbikes