Hello,
I have a small server running a tool (RT : perl + mysql + apache) for our support team. I stripped down everything else. The OS is CentOS 4.8. I noticed a difference between df and du which is hard to believe :
according to df, I am using 29 GB
[root@cedrat-rt ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 33G 29G 2.8G 92% / none 506M 0 506M 0% /dev/shm
(there are no other partitions - ok, I could have partitioned it a bit more)
but according to
du -kshxc /*
my largest directory is /var (because of mysql) and the grand total is
19 GB
I have a 10 GB difference between both outputs.
I verified with
tune2fs -l /dev/sda1 (...) Block count: 8703205 Reserved block count: 435160
that is, the ordinary 5%
the journal size :
debugfs -R "stat <8>" /dev/sda1
yields
Size: 33554432 with a block size of 4096, this gives 128 MB
I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
mounting /dev/sda1, I get the same 29 GB used
e2fsck reports a clean filesystem
e2fsck -f does not reports further errors.
Does anybody have a suggestion ?
Best regards --- Robert GRASSO - System engineer
On Mon, Feb 1, 2010 at 8:29 AM, Robert Grasso robert.grasso+nv@cedrat.com wrote:
Hello,
I have a small server running a tool (RT : perl + mysql + apache) for our support team. I stripped down everything else. The OS is CentOS 4.8. I noticed a difference between df and du which is hard to believe :
according to df, I am using 29 GB
[root@cedrat-rt ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 33G 29G 2.8G 92% / none 506M 0 506M 0% /dev/shm
(there are no other partitions - ok, I could have partitioned it a bit more)
but according to
du -kshxc /*
my largest directory is /var (because of mysql) and the grand total is
19 GB
I have a 10 GB difference between both outputs.
I verified with
tune2fs -l /dev/sda1 (...) Block count: 8703205 Reserved block count: 435160
that is, the ordinary 5%
the journal size :
debugfs -R "stat <8>" /dev/sda1
yields
Size: 33554432 with a block size of 4096, this gives 128 MB
I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
mounting /dev/sda1, I get the same 29 GB used
e2fsck reports a clean filesystem
e2fsck -f does not reports further errors.
Does anybody have a suggestion ?
Best regards
Robert GRASSO - System engineer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This is typical. There were probably files deleted from the file system that are still in use by a process. Restarting the process will release the files and df and du will jive.
On Mon, Feb 1, 2010 at 10:36 AM, Matt Iavarone matt.iavarone@gmail.com wrote:
This is typical. There were probably files deleted from the file system that are still in use by a process. Restarting the process will release the files and df and du will jive.
That argument only holds until you reach the point in the email where he said this: > I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
After the reboot that would be taken care of, so that's not the issue here.
> I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
After the reboot that would be taken care of, so that's not the issue here.
My understanding of the difference between df and du was that du reports the actual size of the file while df reports the space allocated by the filesystem.
So if a filesystem allocates 64KB per block and a file is only 2KB, du will report 2KB and df will report 64KB.
I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
After the reboot that would be taken care of, so that's not the issue here.
My understanding of the difference between df and du was that du reports the actual size of the file while df reports the space allocated by the filesystem.
So if a filesystem allocates 64KB per block and a file is only 2KB, du will report 2KB and df will report 64KB.
There's also the possibility of a lot of hard links.
mark
On Mon, Feb 1, 2010 at 8:43 AM, Brian Mathis brian.mathis@gmail.com wrote:
On Mon, Feb 1, 2010 at 10:36 AM, Matt Iavarone matt.iavarone@gmail.com wrote:
This is typical. There were probably files deleted from the file system that are still in use by a process. Restarting the process will release the files and df and du will jive.
That argument only holds until you reach the point in the email where he said this: > I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
After the reboot that would be taken care of, so that's not the issue here. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I guess I glossed over that part. It could be related to mysql (the storage engine, metadata). du may not be able to parse that information(?).
On Monday 01 February 2010, Brian Mathis wrote:
On Mon, Feb 1, 2010 at 10:36 AM, Matt Iavarone matt.iavarone@gmail.com
wrote:
This is typical. There were probably files deleted from the file system that are still in use by a process. Restarting the process will release the files and df and du will jive.
That argument only holds until you reach the point in the email where
he said this: > I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
Indeed. At this point I'd start looking at things hiding under mount points. But as the OP seems to have only one filesystem, /, then this will be limited to mount-points for special filesystems (like sys, proc and /dev/shm).
What I'm getting at is that you could have, for example, a 10G file /proc/foo on the actaul /-filesystem. As soon as proc is mounted on /proc this would be invisible.
/Peter
After the reboot that would be taken care of, so that's not the issue here.
Thank you everybody !
I have been damned stupid, or tired - or both !
Actually, the file was hidden behind a mount point which failed briefly, but long enough so that a backup took place - and was dumped onto the filesystem - then the mount resumed, and hid the 10 GB backup !!!
Thanks again !
--- Robert GRASSO System engineer
CEDRAT S.A. 15 Chemin de Malacher - Inovallée - 38246 MEYLAN cedex - FRANCE Phone: +33 (0)4 76 90 50 45 - Fax: +33 (0)4 56 38 08 30 mailto:robert.grasso@cedrat.com - http://www.cedrat.com
-----Message d'origine----- De : centos-bounces@centos.org [mailto:centos-bounces@centos.org] De la part de Peter Kjellstrom Envoyé : 1 février 2010 17:03 À : centos@centos.org Objet : Re: [CentOS]very large difference between df and du (10 GB, hard to believe )
Indeed. At this point I'd start looking at things hiding under mount points.
At Mon, 1 Feb 2010 08:36:29 -0700 CentOS mailing list centos@centos.org wrote:
On Mon, Feb 1, 2010 at 8:29 AM, Robert Grasso robert.grasso+nv@cedrat.com wrote:
Hello,
I have a small server running a tool (RT : perl + mysql + apache) for our support team. I stripped down everything else. The OS is CentOS 4.8. I noticed a difference between df and du which is hard to believe :
according to df, I am using 29 GB
[root@cedrat-rt ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 33G 29G 2.8G 92% / none 506M 0 506M 0% /dev/shm
(there are no other partitions - ok, I could have partitioned it a bit more)
but according to
du -kshxc /*
This might be wrong -- are there any files starting with '.' under /? What does 'du -kshxc /' display?
Are df and du *still* off after the reboot?
When you boot with the live CD is df and du *still* off? With the live CD, what does a 'du -sh /mnt/<mumble>/{sys,proc,dev}' show (where <mumble> is the mount point for you hard drive partition)? In other words, do you have stuff under the various tmpfs/kernel mount points?
my largest directory is /var (because of mysql) and the grand total is
19 GB
I have a 10 GB difference between both outputs.
I verified with
tune2fs -l /dev/sda1 (...) Block count: 8703205 Reserved block count: 435160
that is, the ordinary 5%
the journal size :
debugfs -R "stat <8>" /dev/sda1
yields
Size: 33554432 with a block size of 4096, this gives 128 MB
I rebooted on the CentOS v4.8 CD #1, started "linux rescue" :
mounting /dev/sda1, I get the same 29 GB used
e2fsck reports a clean filesystem
e2fsck -f does not reports further errors.
Does anybody have a suggestion ?
Best regards
Robert GRASSO - System engineer
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This is typical. There were probably files deleted from the file system that are still in use by a process. Restarting the process will release the files and df and du will jive.
The OP rebooted with a live CD, which should have dealt with any lingering processes :-)
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Grasso wrote, On 02/01/2010 10:29 AM:
Hello,
<SNIP>
CentOS 4.8. I noticed a difference between df and du which is hard to believe :
according to df, I am using 29 GB [root@cedrat-rt ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 33G 29G 2.8G 92% / none 506M 0 506M 0% /dev/shm
(there are no other partitions - ok, I could have partitioned it a bit more) but according to
du -kshxc /* my largest directory is /var (because of mysql) and the grand total is 19 GB
I have a 10 GB difference between both outputs.
<SNIP>
e2fsck reports a clean filesystem
<SNIP>
Does anybody have a suggestion ?
<commentary on options> -k is 1k block size -h is print human readable (with appropriate extensions) which ever of them is last wins for display... I suggest only using one though, to reduce possible confusion. for large measurements I usually use -m, of course it could be fun to use --block-size=1024M instead, i.e., 1G. </commentary on options>
I too would expect them to come close to matching, unless you have a lot of 3.5k (or less) files in a 4k inode file system.
du -shxc --count-links /* du -shxc --apparent-size /* du -shxc --count-links --apparent-size /*
Robert Grasso wrote:
Hello,
I have a small server running a tool (RT : perl + mysql + apache) for our support team. I stripped down everything else. The OS is CentOS 4.8. I noticed a difference between df and du which is hard to believe :
Did you mount something such as an NFS share over a directory that has stuff in it?
Ryan
-
Brian Mathis -
Drew -
m.roth＠5-cent.us -
Matt Iavarone -
Peter Kjellstrom -
Robert Grasso -
Robert Heller -
Ryan Pugatch -
Todd Denniston