df 显示的已使用磁盘占用率比du 统计出来的结果要大很多。原因,主要是由于两者计算结果的方式不同。
一、实验情况
1、创建并删除文件
创建文件前的磁盘容量情况:
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
创建文件:
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 14.3055 seconds, 73.3 MB/s
现在的磁盘情况:
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm
模拟某个进程正在使用该文件:
# tail -f /tmp/test.iso |
2、删除该文件
打开另一个终端,登陆到系统中。
查看是否有进程正在使用上面创建的文件:
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso
把该文件删掉,并确认:
rm:是否删除 一般文件 “/tmp/test.iso”? y
# ls /tmp/test.iso
ls: /tmp/test.iso: 没有那个文件或目录
查看是否还有进程在使用(注意结尾的标记):
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso ( deleted)
查看磁盘使用情况:
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 6.7G 4.6G 60% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54385 5184 1626626 130090 20434 635997 5251448 5345733 0 111685 5475829
可见,虽然从ls 已经无法找到该文件,但因为tail 进程仍在使用该文件,故实际上内核并没有把这文件所占用的空间释放出来(df 的结果)。
3、停止相关进程
回到第一终端,用Ctrl+C 终止tail 进程,查看结果:
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# cat /proc/diskstats |grep sda1
8 1 sda1 54473 5184 1627402 130617 20453 636042 5251960 5345756 0 112226 5476379
至此,文件所占用的空间已完全释放。
二、说明
从上面的实验,可得出一些情况:
2、df 是从内核中获取磁盘占用情况数据的,而du是统计当前磁盘文件大小的结果,由于磁盘标记已被删掉,因此du 不会计算上述被删除文件的空间,导致df 与 du的结果不一致。
三、解决问题
通常的解决方法有两个:
1、把占用文件的相关进程关闭
这可通过下面的命令得到这些已被删除,但未释放空间的文件和进程信息:
# lsof |grep deleted |
找到这些进程后,在安全的情况下把其关闭,空间自会马上释放。
2、以清空的方式替代删除
归根到底,产生问题的原因是,访问该文件的文件指针(句柄),在rm 动作后,因为进程仍在访问,因此,仍处在文件里面(中间或结尾处)。所以,如果用清空的方式,把文件指针重置,该文件所占用的空间也会马上释放出来。
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# tail -f /tmp/test.iso
tail: /tmp/test.iso: file truncated
所以,对于常发生类似问题的文件,如:日志记录文件等。以改名、清空、删除的顺序操作可避免问题。
四、补充
除rm外,有些不明显的操作,也会产生类似的问题。
例如 gzip 命令,其对某个文件xxx.log进行压缩时,会产生一个新的xxx.log.gz文件,完成后,会把原来的xxx.log删除。
这时,若仍有进程在使用xxx.log文件,那么,实际上,该文件还是只会标记为deleted,其空间也不会释放,问题与上面提到的情况是相同的。所以,在编写脚本时,可先判断是否仍有进程正在使用该文件,然后再进行gzip 操作。
五 文件空洞
文件读写时,如果先文件指针偏移很大一段,然后写入1byte;这样这个文件实际占用1byte空间,但是stat查看文件大小,或者读写时,都会发现文件很大;所有没有写内容的都返回0,且不占用空间,这样的文件叫 'sparse file',即文件空洞
容易发生在一个进程在写一个文件,这是人工进行清空文件操作,就会产生。
dd if=/dev/zero of=test bs=1M count=1000
会生成一个1000M的test文件,文件内容为全0(因从/dev/zero中读取,/dev/zero为0源),但是这样为实际写入硬盘,文件产生速度取决于硬盘读写速度,如果欲产生超大文件,速度很慢。在某种场景下,我们只想让文件系统认为存在一个超大文件在此,但是并不实际写入硬盘
则可以
dd if=/dev/zero of=test bs=1M count=0 seek=100000
此时创建的文件在文件系统中的显示大小为100000MB,但是并不实际占用block,因此创建速度与内存速度相当,seek的作用是跳过输出文件中指定大小的部分,这就达到了创建大文件,但是并不实际写入的目的。当然,因为不实际写入硬盘,所以你在容量只有10G的硬盘上创建100G的此类文件都是可以的
综上所述,在运维Linux服务器时,会碰到需要查看硬盘空间的情况,这时候,通常会使用df -lh命令来检查每个挂载了文件系统的硬盘的总量和已使用量,或者,可以使用du -sh [directory]命令来统计某个目录下所有文件的空间占用。
在使用df、du命令时,常常会遇到统计的硬盘使用情况不一致的问题。比如du统计根目录下文件总共大小为2G,而df判断挂载在根目录的硬盘已用空间达到了3G,20G甚至更多。发生这种情况,有以下三种原因:
为了预防紧急情况,linux ext文件系统会预留部分硬盘空间,具体预留的数值可以通过tune2fs -l [dev_name] | grep “Reserved block count”查看到(dev_name是设备名),这里预留的空间会被df计算到已用空间中,从而导致df和du统计不一致。如果需要调整预留空间大小,我们可以使用tune2fs -m [size] [dev_name]来进行调整。
du
是统计被文件系统记录到的每个文件的大小,然后进行累加得到的大小,这是通过文件系统获取到的。而df主要是从超级块(superblock)中读入硬盘使用信息,df获取到的是磁盘块被使用的情况。当一个文件被删除时,如果有别的进程正在使用它(占有句柄), 这个文件将不会被du统计到,但是这个文件被占用的磁盘空间却依然会被df统计到。这些文件,以及正在使用这些文件的进程可以通过lsof | grep deleted查到。当进程停止或者被kill时,这些空间将被释放。
如果上面两种情况都排除了,
但是数据还是不一致,那是怎么回事?这里隐藏着一种情况:当我们将一个目录挂在到一个新的设备(硬盘)上之前,如果这个目录里面已经有数据,那么这一部分数据不会被du感知,在文件系统中也看不到这些数据,但是这些数据又是确实占用了磁盘空间,是能够被df所统计到的。这时候通过du/df统计原设备的空间使用情况,就会发现df统计到的比du要多。遇到这样的情况时,使用fuser -km [directory]杀死占用该目录的所有进程(小心操作!),然后使用umount [directory]将该目录挂载的设备卸载,这时,目录里面原来已有的数据就会出现,我们将其删除之后,再重新挂载设备(mount -t [type] [dev] [directory])即可。