文件系统

文件系统只读有两种：卷只读和 Linux 只读。卷只读是存储侧控制，能恢复；Linux 只读是存储 IO 错误触发的保护机制，remount 基本失败，只能重启。 现象 虚拟机文件系统变成只读： root@host:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 20G 0 disk └─vda1 253:1 0 20G 0 part / vdb 253:16 0 4G 0 disk [SWAP] vdc 253:32 0 100G 0 disk root@host:~# touch test touch: cannot touch 'test': Read-only file system 同事说另一个类型的虚拟机只读了能恢复，这个怎么恢复。 排查 先要分清是"卷只读"还是"Linux 只读"，两者恢复方式完全不同。 再确认存储是否中断过，因为 Linux 只读通常由存储 IO 错误触发。 根因 同事那个能恢复，是因为不是 Linux 只读，而是卷只读。那个卷是我们公司自己的存储，能控制其读写权限。 但这里 Linux 只读，一般是存储读写有 IO error，触发了 Linux 保护机制，系统只读。 我问他是不是存储中断过，他说是的。 这种 Linux 只读没法恢复，remount 基本失败，只能重启虚拟机。 小结 Linux 文件系统只读，通常是存储 IO 错误触发的保护机制； 卷只读（存储侧控制）可以恢复，Linux 只读（IO 错误触发）基本无法 remount 恢复； 排查时先确认是"卷只读"还是"Linux 只读"，两者恢复方式完全不同； Linux 只读只能重启虚拟机恢复。

报 no space left on device，看上去是磁盘空间不足，但有可能不是存储满了，而是 inode 满了。用 df -i 查看 inode 使用情况，如果有 100% 的就是 inode 满了。 现象 报 no space left on device，看上去是磁盘空间不足了，那么找没用的文件删了即可。 但有可能不是存储满了，而是 inode 满了。 排查 使用 df -i 查看 inode 的使用情况，如果有 100% 的，那就说明是 inode 满了： root@host:~# df -i Filesystem Inodes IUsed IFree IUse% Mounted on udev 16059428 1017 16058411 1% /dev tmpfs 16078645 1812 16076833 1% /run /dev/sda2 3276800 154963 3121837 5% / tmpfs 16078645 4 16078641 1% /dev/shm tmpfs 16078645 13 16078632 1% /run/lock tmpfs 16078645 18 16078627 1% /sys/fs/cgroup /dev/sda4 31162368 4308 31158060 1% /data /dev/sdb1 182939648 564 182939084 1% /data/container 然后查找哪里小文件特别多。 ...

删除文件后磁盘空间没释放，是因为文件被进程打开，进程还持有文件描述符。用 lsof | grep deleted 找到占用进程，最好的方法是在线清空文件。 现象 在 Linux 或者 Unix 系统中，通过 rm 或者文件管理器删除文件，磁盘空间却没有释放。 根因 通过 rm 删除文件，只是将它从文件系统的目录结构上解除链接（unlink），也就是说只是删除了文件和系统目录结构的链接。 如果文件在删除时是被打开的（有一个进程正在使用该文件，文件被进程锁定或者有进程一直在向这个文件写数据等）状态，那么进程将仍然可以读取该文件，进程还持有文件的文件描述符 fd，所以磁盘空间也就会一直被占用。 一个文件在文件系统中的存放分为两个部分：数据部分和指针部分。 指针位于文件系统的 meta-data 中，数据被删除后，这个指针就从 meta-data 中清除了； 而数据部分存储在磁盘中，数据对应的指针从 meta-data 中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容； 之所以出现删除文件后空间还没释放，就是因为有进程还在一直向这个文件写入内容，导致虽然删除了文件，但文件对应的指针部分由于进程锁定，并未从 meta-data 中清除； 而由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过 df 命令查询空间并未释放也就不足为奇了。 解决办法 1. 找到占用进程并 kill 通过 lsof | grep deleted 命令获取到已经被删除但是仍然被应用程序占用的文件列表，然后 kill 掉还在占用所删除文件的进程。 需要注意的是：如果有很多进程都在使用所删除文件，那么采用这种方式 kill 进程就有点麻烦了，而且风险也比较大。 因为 kill 进程是通过截断 proc 文件系统中的文件可以强制要求系统回收分配给正在使用的文件。 必须要确定不会对运行中的进程造成影响时才能使用，应用程序对这种方式支持的并不好，当一个正在使用的文件被截断可能会引发不可预知的问题。 2. 停掉或重启应用 停掉或重启使用这个所删除文件的应用，让 OS 自动回收磁盘空间。 3. 重启操作系统 也可以重启操作系统，不过这并不是最好的方法。 4. 在线清空文件（推荐） 对待这种进程不停对文件写日志的操作，要释放文件占用的磁盘空间，最好的方法是在线清空这个文件。 通过这种方法，磁盘空间不但可以马上释放，也可保障进程继续向文件写入日志。 在线清空文件（比如 /var/log/app.log）的方式： ...