• Linux 磁盘100%


    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)

  • 相关阅读:
    HTML<head></head>中标签的含义
    axios发送post请求node服务器无法通过req.body获取参数
    Vue下URL地址栏参数改变却不能刷新界面
    Vue中img标签src属性绑定
    vue-cli 初始化项目时开发环境中的跨域问题
    【CODEVS2152】滑雪
    【NOIP2005】过河
    【CODEVS2776】寻找代表元
    【CodeVS1231】最优布线问题
    【CODEVS1073】家族
  • 原文地址:https://www.cnblogs.com/amandaysu/p/3658079.html
Copyright © 2020-2023  润新知