JFS2 上 df -k 与 du -sk 统计不相同

victorxu79

请问大狭:

有没有见过在AIX 5300-04-CSP 上,df -k 统计的(总空间-空闲空间)信息与du -sk 使用空间不相同 ?

md1204

上次看到过一个类似的贴子,后来不知怎么解决的.呵呵

victorxu79

会不会是superblock 有问题了? 或是bug ?

tedy888

du 和 df的不同
du和df命令都被用于获得文件系统大小的信息：df用于报告文件系统的总块数及剩余块数，du -s /<filesystem>用于报告文件系统使用的块数。但是，我们可以发现从df命令算出的文件系统使用块数的值与通过du命令得出的值是不一致的。如下例：
# du -s /tmp 返回如下值：
12920 /tmp
而 df /tmp返回如下值：
Filesystem 512-blocks Free %Used Iused %Iused Mounted on
/dev/hd3 57344 42208 26% 391 4% /tmp
从上面的值我们可以算出<total from df> - <Free from df> = <used block count>: 57344 - 42208 = 15136. 而15136大于12920。该值差异的存在是由于du与df命令实施上的不同: du -s命令通过将指定文件系统中所有的目录、符号链接和文件使用的块数累加得到该文件系统使用的总块数；而df命令通过查看文件系统磁盘块分配图得出总块数与剩余块数。
文件系统分配其中的一些磁盘块用来记录它自身的一些数据，如i节点，磁盘分布图，间接块，超级块等。这些数据对大多数用户级的程序来说是不可见的，通常称为Meta Data。
du命令是用户级的程序，它不考虑Meta Data，而df命令则查看文件系统的磁盘分配图并考虑Meta Data。df命令获得真正的文件系统数据，而du命令只查看文件系统的部分情况。例如，一个frag=4096 并且 nbpi=4096的空的大小为4MB的日志文件系统中Meta Data的分配情况如下：
1 4k block for the LVM
2 4k super blocks
2 4k blocks for disk maps
2 4k blocks for inode maps
2 4k blocks for .indirect
32 4k blocks for inodes
-------------------------
41 4k blocks for meta data on an empty 4MB file system
对于AIX 4.X版本：
执行 du /foo返回的结果如下：
8 /foo/lost+found
16 /foo
要使du命令输出的结果与df命令输出的结果匹配，我们必须要加上Meta Data。首先，将41个4k的块转换为以512字节为单位的值：
41 * 8 = 328
328(meta data) + 16(from du) = 344
所以有344个以512字节为单位的块分配给了这个空的文件系统。
而使用 df /foo命令我们可以得到下面的结果：
Filesystem 512-blocks Free %Used Iused %Iused Mounted on
/dev/lv01 8192 7848 5% 16 2% /foo
从中我们可以得到该文件系统使用的块数：8192(total blocks) - 7848(free blocks) = 344。该值与上面得出的值一致。
上面的换算方法对于空的文件系统很容易实现，但是对于非空的文件系统，由于Meta Data中文件间接块的大小不定，因此较难实现。所以我们不需要查看du 与 df返回的值的匹配关系，而只需要了解du -s命令返回的值反映了分配给文件及目录的磁盘块数，而df命令则反映了文件系统的实际分配情况。df命令反映的实际情况包含了用户数据（文件及目录）和Meta Data。
另一个表现出du与df命令不同之处的例子如下：
如果用户删除了一个正在运行的应用所打开的某个目录下的文件，则du命令返回的值显示出减去了该文件后的目录的大小。但df命令并不显示减去该文件后的大小。直到该运行的应用关闭了这个打开的文件，df返回的值才显示出减去了该文件后的文件系统的使用情况。

chenwei.js

我这边有一个文件系统，主要用于存放应用程序的可执行文件，应该不存在4楼所说的第二种情况，但是运行一段时间后，df输出的结果比du的结果大很多，甚至好几倍，执行slibclean命令后可缓解这种情况，不知怎么回事，请兄弟们帮忙。

chenwei.js

4楼的兄弟，能不能帮我参谋一下。

meilixueshan

大好几倍不正常，估计是碎片，用defragfs整理一下看看