在RedHat 6服务器上，我们遇到了在线调整ext4文件系统的问题。
在只有/ dev / sda的情况下，我们在卷组中有13GB，但在一个36GB的逻辑卷上需要20GB以上的空间。 将/ dev / sdb添加到卷组，并将文件系统扩展（lvextend）并将其大小调整为（resize2fs）为56GB。 在resize期间没有错误消息，操作系统报告了新的大小。
有问题的逻辑卷承载IBM HTTP Server（apache 2.2）的安装，用于一些8个不同的Web服务器的configuration和日志文件。
今天早上文件系统使用增长超过36GB。 首先发生的事情是，Web服务器停止日志logging（发现后），而Web服务器保持运行没有问题。 2.5个小时后，关于日志轮换和其他写入文件系统的事情开始冻结。 含义：networking服务器停止了stream量，所有进程都停留了，试图“挂掉”一个日志文件将挂起，并且不能被中断。 服务器的负载从0.10到4000（是的…） – 主要与iowait有关（看起来）。
解决办法是closuresnetworking服务器 – kill -9是唯一的方法，并重新启动服务器。 卸载文件系统，做了一个fsck（没有错误），然后重新开始。 没有问题，因为。
当磁盘（lv）的使用增长到36GB以前，我们可以用logging停止的时间来精确地计时错误。
其他文件系统上的服务似乎运行良好，其中包括操作系统。
在我们看到的/ var / log / messages中，即：
kernel: INFO: task httpd:<pid> blocked for more than 120 seconds. kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: httpd D 0000000000000001 0 6889 6865 0x00000080 kernel: ffff88023aa99c88 0000000000000086 0000000000000000 0000000000006102 kernel: ffff88010aebaa80 ffff880105dd0ae0 000000003aa99c08 ffff880105dd0ae0 kernel: ffff880105dd1098 ffff88023aa99fd8 000000000000fb88 ffff880105dd1098 kernel: Call Trace: kernel: [<ffffffff8150efbe>] __mutex_lock_slowpath+0x13e/0x180 kernel: [<ffffffff8150ee5b>] mutex_lock+0x2b/0x50 kernel: [<ffffffff8111c461>] generic_file_aio_write+0x71/0x100 kernel: [<ffffffffa0097fb1>] ext4_file_write+0x61/0x1e0 [ext4] kernel: [<ffffffff81180d7a>] do_sync_write+0xfa/0x140 kernel: [<ffffffff81096ca0>] ? autoremove_wake_function+0x0/0x40 kernel: [<ffffffff8121bc06>] ? security_file_permission+0x16/0x20 kernel: [<ffffffff81181078>] vfs_write+0xb8/0x1a0 kernel: [<ffffffff81181971>] sys_write+0x51/0x90 kernel: [<ffffffff810dc645>] ? __audit_syscall_exit+0x265/0x290 kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b 版本：
Kernel: 2.6.32-358.2.1.el6.x86_64 lvm2-2.02.98-9.el6.x86_64 e2fsprogs-1.41.12-14.el6.x86_64
没有发现底层硬件的问题。
答案是：文件系统是用mke2fs <device>创build的
然后默认的行为是创build一个ext2文件系统。 然而，它被作为一个ext4文件系统挂载 – 没有任何错误信息 – 后来被认为是一个ext4文件系统。
所以难怪在线resize工作，难怪扩展部分是在卸载/挂载或重新启动后识别。
花了一段时间才发现，因为在创作和调整之间有很长一段时间，而且在运行blkid （ext2）时终于发现了。 tune2fs -l也表示“不干净”。