问题场景一：文件系统损坏导致系统无法启动

在检查根文件系统时，发现/dev/sda6分区包含错误的文件系统，此时需要强制进行检查修复。

umount /dev/sda6
fsck.ext3 -y /dev/sda6

问题场景二：“Argument list too long” 错误及其解决方案

在编辑并尝试保存crontab时，出现“no space left on device”的错误提示，得知磁盘空间已满。

df -h

显示/var分区空间已达到100%，问题根源在于/var目录下磁盘空间已满，因crontab保存时会在/var目录下写入文件信息。进一步通过du命令检查/var目录下各文件和目录大小，发现/var/spool/clientmqueue占据约90%的空间，这些文件主要是邮件信息，可以安全删除。

rm /var/spool/clientmqueue/*

若遇到“argument list too long”错误，可通过以下方法解决：

分批次删除：

rm [a-n]* -rf
rm [o-z]* -rf

使用find命令：

find /var/spool/clientmqueue -type f -print -exec rm -f {} ;

编写shell脚本逐个删除：

#!/bin/bash
RM_DIR='/var/spool/clientmqueue'
cd $RM_DIR
for I in `ls`
do
    rm -f $i
done

重新编译内核以增大命令行参数限制（非常规方案）。

问题场景三：inode耗尽导致应用故障

一台Oracle数据库在重启后，监听服务无法启动，提示磁盘空间不足。经检查并非物理磁盘空间问题，而是inode节点耗尽所致。

df -i
dumpe2fs -h /dev/sda3 | grep 'Inode count'
find /var/spool/clientmqueue/ -name "*" -exec rm -rf {} ;

通过清理inode节点占用过高的文件解决此问题。

问题场景四：文件已被删除但空间未释放

运维监控系统报警服务器磁盘空间已满。经过排查，发现/tmp目录下大文件占用空间，且/tmp与根分区共享空间。在确认可删除/tmp下大文件后，却发现空间未被释放，原因是httpd进程仍在向已被删除的access_log文件写入日志。

lsof | grep delete
echo "" >/tmp/access_log

通过终止或重启httpd进程，或直接清空文件内容以释放磁盘空间。

问题场景五：“too many open files”错误及其解决方法

在Java web应用中收到“too many open files”错误提示。通过ulimit命令查看当前用户可打开的最大文件描述符数量，并在limits.conf文件中设置了正确的限制值，但问题依然存在。经过排查发现，由于limits.conf的修改是在Tomcat启动之后，导致配置未生效。解决方法是重启Tomcat服务使新配置生效。

问题场景六：“Read-only file system”错误及其解决方法

当文件系统因数据块不一致或磁盘故障等问题变为只读时，可以使用fsck命令进行修复。但在修复之前，应先卸载受影响的磁盘分区。如果遇到设备忙无法卸载的情况，需先找出并关闭占用该分区的进程，随后执行fsck命令进行修复，最后重新挂载该分区。

fuser -m /dev/sdb1
ps -ef | grep <PID>
kill <PID> (或停止相应服务)
umount /www/data
fsck -V -a /dev/sdb1
mount /dev/sdb1 /www/data