[solved] df shows inconsistent numbers - a lot of 'lost' space

bizna · 02-03-2011, 01:50 AM

There is a very conspicuous inaccuracy in the output of df. I should mention, that it was noticed to to a sudden change in the amount of space that was left on the backup partition.

The df -h command produces the following output.

Code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdi1             936G  884G  4.3G 100% /backups

My suspicion was immediately directed towards sparse files. The script I found on the following link, found too many files, and no immediate culprit. A script for locating sparse files:

Code:

#!/bin/sh
# even in 30, it reduced too many results
typeset -i TOL=3 # plus or minus 3 blocks
while [[ ${#} -ge 1 ]]
  do
    typeset FNAME=${1}
    shift
    typeset -i SZ=$(ls -l "${FNAME}" | awk '{print $5}')
    typeset -i DUSZ=$(du -k "${FNAME}" | awk '{print $1}')
    typeset -i RSLT=$(echo "scale=0; h=0; a=(${SZ} / 1024) - ${DUSZ}; if (a < -${TOL}) h=1; if (a > ${TOL}) h=1; h" | bc)
    if [[ ${RSLT} -ne 0 ]]
      then
        echo "${FNAME}"
      fi
  done
exit 0

The question is: what can be the reason for this inaccuracy?

The server is a run-of-the-mill Centos, with a standard LAMP configuration.

For obvious reasons, the server can't be taken down for an fsck check. And anyway, the problem is not in the '/backups/' partition, as it is only storing data from other locations.

Any ideas?

syg00 · 02-03-2011, 08:20 PM

Quote:

Originally Posted by bizna

There is a very conspicuous inaccuracy in the output of df.

You've offered no evidence to support this claim.

Quote:

My suspicion was immediately directed towards sparse files.

Why ?. Sparse files have no adverse impacts on what "df" outputs - the "apparent size" is not included. At least on my test systems - I don't have CentOS handy at the moment, but I've been doing sparse testing for ages.

Quote:

And anyway, the problem is not in the '/backups/' partition, as it is only storing data from other locations.

Supposition by you - until you can fsck it you can't make that assertion.

Reuti · 02-04-2011, 05:14 AM

Looks like the usual 5% reserved for the root account on /dev/sdi1 is making the difference. You can use e.g. tune2fs to adjust it.

bizna · 02-06-2011, 01:11 AM

Quote:

Originally Posted by Reuti

Looks like the usual 5% reserved for the root account on /dev/sdi1 is making the difference. You can use e.g. tune2fs to adjust it.

Right you are!

The following command allowed to reclaim the 'lost' space:
tune2fs -m 0 /dev/sdi1

And regarding the sparse files, I've found out some very big differences between the du and the ls, when looking at the big MySQL ibd files. Sadly enough, the only safe way of getting rid of that empty space, is by export/import to a new DB.

Thanks for all the help!