Results 1 to 2 of 2
I have been tasked with finding out why we appear to be running out of disk space on our Redhat server and am coming across some strange inconsistencies in the ...
- 04-23-2010 #1Just Joined!
- Join Date
- Apr 2010
- Posts
- 1
Troubleshooting disk space problems/inconsistencies
I have been tasked with finding out why we appear to be running out of disk space on our Redhat server and am coming across some strange inconsistencies in the way disk use is reported.
For example, df -h is showing...
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
63G 56G 3.9G 94% /
/dev/sda1 99M 19M 76M 20% /boot
tmpfs 7.9G 0 7.9G 0% /dev/shm
/dev/mapper/VolGroup01-LogVol03
3.6T 431G 3.0T 13% /raid
//172.16.6.55/data-a 196G 161G 36G 82% /mnt/k
//172.16.6.82/gis 373G 280G 94G 75% /mnt/mm
The odd thing is that we can't see what is using up 56G on /
I've tried to post a URL to the Baobab output but this forum won't let me.
I don't really understand the way the filesystem has been set up here, but we've calculated that only the following actually exists on / ....
tmp 168K
var 8.4GB
usr 5.5GB
sbin 33MB
lost-found 16K
media 0
root 1.1GB
bin 7.3MB
boot 13MB
....which is far below the 56G reported by df
Obviously this is critical, any insights would be gratefully received.
Martin.
- 04-27-2010 #2Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
Boot from a recovery/live CD/DVD and run fsck -f on your root file system, which should be /dev/sdaN where N is the partition associated with /. BTW, if you used the 'du' command to get the sizes of the components in /, it does not traverse links by default. Anyway, fsck will reclaim "lost" space on the drive.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!


Reply With Quote