Re: df bigger than ls?

Brian Candler
2012-03-07T17:16:22Z

On Wed, Mar 07, 2012 at 03:54:39PM +0000, Brian Candler wrote:
> core.size = 1085407232
> core.nblocks = 262370

core.nblocks is correct here: space used = 262370 * 4 = 1049480 KB

(If I add up all the non-hole extents I get 2098944 blocks = 1049472 KB
so there are two extra blocks of something)

This begs the question of where stat() is getting its info from?

Ah... but I've found that after unmounting and remounting the filesystem
(which I had to do for xfs_db), du and stat report the correct info.

In fact, dropping the inode caches is sufficient to fix the problem:

root@storage1:~# du -h /disk*/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk10/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk11/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk12/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk1/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk2/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk3/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk4/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk5/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk6/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk7/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk8/scratch2/work/PRSRA1/PRSRA1.1.0.bff
2.0G /disk9/scratch2/work/PRSRA1/PRSRA1.1.0.bff
root@storage1:~# echo 3 >/proc/sys/vm/drop_caches
root@storage1:~# du -h /disk*/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk10/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk11/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk12/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk1/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk2/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk3/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk4/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk5/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk6/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk7/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk8/scratch2/work/PRSRA1/PRSRA1.1.0.bff
1.1G /disk9/scratch2/work/PRSRA1/PRSRA1.1.0.bff
root@storage1:~#

Very odd, but not really a major problem other than the confusion it causes.

Regards,

Brian.