0

I have a server which has a handful of services (Apache, MySQL, DNS, Nagios), and have been having issues with the harddrive filling up. Upon further review, I noticed that the percentage used according to df doesn't make any sense. Used space plus available space does not equal total space. At the time I first became aware of this (thanks to a Nagios notification), the available space was less than 1 GB out of our 40 GB harddrive. According to du and df "Used" column, the actual used was 11GB. That's a difference of 28GB. At the moment it's fluctuating only a little, but sometimes it fluctuates at over 1000 bytes per second. See here:

$ df / && sleep 5 && df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vzfs             41943040  11398324  29195724  29% /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vzfs             41943040  11398324  29173016  29% /

This is a VPS that I don't have physical access to. It's running XFS, so a normal reboot fsck isn't an option either. It doesn't do it constantly, and log files don't seem to indicate anything going on. iotop doesn't even show any activity at all. Twist, we have people actively using this machine so we can't just format.

Output of df -a:

$ sudo df -a
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vzfs             41943040  11398740  29064180  29% /
proc                         0         0         0   -  /proc
sysfs                        0         0         0   -  /sys
none                    524288         4    524284   1% /dev
none                         0         0         0   -  /dev/pts
none                   5242880        12   5242868   1% /var/tmpfs
none                         0         0         0   -  /proc/sys/fs/binfmt_misc
/etc/named            41943040  11398740  29064180  29% /var/named/chroot/etc/named
/var/named            41943040  11398740  29064180  29% /var/named/chroot/var/named
/etc/named.rfc1912.zones
                      41943040  11398748  29064172  29% /var/named/chroot/etc/named.rfc1912.zones
/etc/rndc.key         41943040  11398748  29064172  29% /var/named/chroot/etc/rndc.key
/usr/lib64/bind       41943040  11398756  29064164  29% /var/named/chroot/usr/lib64/bind
/etc/named.iscdlv.key
                      41943040  11398764  29064156  29% /var/named/chroot/etc/named.iscdlv.key
/etc/named.root.key   41943040  11398772  29064148  29% /var/named/chroot/etc/named.root.key
Drew Noel
  • 1

1 Answers1

2

The filesystem can be constructed from many devices. You need to take a complete look at everything. I'd suggest using the -a switch.

$ df -a
/dev/mapper/fedora_greeneggs-root  51475068  14698136  34139108  31% /
/dev/sda1                            487652    100725    357231  22% /boot
/dev/mapper/fedora_greeneggs-home 420590200 164261484 234940840  42% /home

There are a number of devices that are combined to create the disk space on ones system. If you know the directory where you're running out of space you can always direct df to it like so:

$ df /var/log
Filesystem                        1K-blocks     Used Available Use% Mounted on
/dev/mapper/fedora_greeneggs-root  51475068 14698136  34139108  31% /

This will show you the device + the space available & used based on that directory.

Who's using all my diskspace?

If you'd like to identify the 10 largest directories then take a look at the answer I provided to this U&L Q&A titled: ls with find :: report total size.

Community
  • 1
slm
  • 369,824
  • Added the output from df -a. I don't see anything in particular about it that explains the problem though. Everything runs off the one dev. – Drew Noel Mar 01 '14 at 21:04
  • You say this is a VPS, I noticed that the primary device for you / path is /dev/vzfs. I'd be suspicious of your VPS provider playing games and squeezing your upper bound down temporarily on you, thus causing you to only have 1GB free, and then dynamically increasing this value. They're likely using OpenVZ/Proxmox which you can do this on fairly easily from the host system. The VM guests wouldn't know it other then their space shrinking. – slm Mar 01 '14 at 21:20
  • Thanks, I realized that the filesystem is actually VZFS which appears to be proprietary and so this is indeed the most logical answer. I'll touch base with them. – Drew Noel Mar 01 '14 at 21:24