Linux 磁盘100%

时间：2024-02-18 09:38:46

df -- report file system disk space usage

du -- estimate file space usage

 

当用df -h 命令查看磁盘的使用率，发现有一个盘符/dev/vda5 使用率是99%，

然后用du -h命令查看文件空间， 发现该盘符/dev/vda5 的使用率仍是99%

[root@vmnio51 ~]# df -h /alcatel/
Filesystem            Size  Used Avail Use% Mounted on
/dev/vda5              40G   38G  436M  99% /alcatel

后来查明，有一个路径下，某一个simulator生成了好多文件没有被处理，已达到36G，并且在这个server vmnio51上没有处理这些文件的进程。

所以需要删除这些文件，但是这些文件已经变为了只读。

采取的方案有：

1.init 6重启之后，仍不能删除这些文件，而且server上的进程已经不能被正常启动

2.fsck.ext3 -y /dev/vda5，只能释放3%的空间

3.(effective one as below:)

Removing and re-enabling ext3

 

https://engineering.rackspace.com/dcops/operating_systems/linux/howto-s/removing-and-re-enabling-ext3?searchterm=journal+ab

 

https://core.rackspace.com/py/ticket/view.pt?ref_no=080709-06684

 

If you have to remove and then re-enable a corrupt or aborted ext3 filesystem. Try this for single user, read-only mode.

 

1. tune2fs -O ^has_journal /dev/***   <------ strips the journal

2. fsck the partition

3. tune2fs -j /dev/***    <----- adds back the journal

 

Once this is done, remount the filesystem as read-write (mount -o remount,rw /) and create a test file (touch test.txt) to see if the filesystem is indeed writeable.

 

If this doesn\'t work then a trickier option is also available to you.

 

1. debugfs -w -R "feature ^has_journal, ^needs_recovery" /dev/***

2. fsck the partition e2fsck -y /dev/***

3. tune2fs -j /dev/***

 

If that doesn\'t work the drive is probably hosed. 

 

--------

 

tune2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda5

Can\'t find valid filesystem superblock.

 

hardware error!

 

--------------分割线----------------------

 

文件系统错误
内核相关硬件驱动bug
FW固件类问题
磁盘坏道
硬盘背板故障
硬盘线缆故障
HBA卡故障
RAID卡故障

 

---------------分割线------------------------

在linux中，当我们使用rm在linux上删除了大文件，但是如果有进程打开了这个大文件，却没有关闭这个文件的句柄，那么linux内核还是 不会释放这个文件的磁盘空间，最后造成磁盘空间占用100%，整个系统无法正常运行。这种情况下，通过df和du命令查找的磁盘空间，两者是无法匹配的， 可能df显示磁盘100%，而du查找目录的磁盘容量占用却很小。

遇到这种情况，基本可以断定是某些大文件被某些程序占用了，并且这些大文件已经被删除了，但是对应的文件句柄没有被某些程序关闭，造成内核无法回收这些文件占用的空间。

那么，如何查找那些文件被某些程序占用呢，命令如下

lsof -n | grep deleted
COMMAND     PID      USER   FD      TYPE             DEVICE        SIZE       NODE NAME
dd        31708      higkoo    1w      REG                8,2 5523705856     429590 /data/filetest (deleted)

命令打lsof -n | grep deleted印出所有针对已删除文件的读写操作，这类操作是无效的，也正是磁盘空间莫名消失的根本原因

[root@vmnio51 ~]# lsof -n | grep deleted
httpd      1526  nobody   14u      REG              253,2      3520    1608107 /opt/apache/logs/jk-runtime-status.4145 (deleted)
httpd      1526  nobody   15u      REG              253,2         1    1608131 /opt/apache/logs/jk-runtime-status.4145.lock (deleted)
oracle     2900  oracle    4w      REG              253,2  10544357    8952147 /opt/app/oracle/grid/11.2.0.3/log/vmnio51/agent/ohasd/oraagent_oracle/oraagent_oracle.l03 (deleted)

相关文章