LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (http://www.linuxquestions.org/questions/linux-server-73/)
-   -   [solved] df shows inconsistent numbers - a lot of 'lost' space - how to find sparse files (http://www.linuxquestions.org/questions/linux-server-73/%5Bsolved%5D-df-shows-inconsistent-numbers-a-lot-of-lost-space-how-to-find-sparse-files-860387/)

bizna 02-03-2011 12:50 AM

[solved] df shows inconsistent numbers - a lot of 'lost' space - how to find sparse files
 
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 07:20 PM

Quote:

Originally Posted by bizna (Post 4246714)
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 04: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 12:11 AM

Quote:

Originally Posted by Reuti (Post 4248049)
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!


All times are GMT -5. The time now is 03:02 AM.