Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Unix is not my native language and I'm getting confused by their concept of filesystems.

When I look at my free space I see:

/$ df -kh
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  7.1G  397M  95% /
none                  3.7G  120K  3.7G   1% /dev
none                  3.7G  4.0K  3.7G   1% /dev/shm
none                  3.7G   48K  3.7G   1% /var/run
none                  3.7G     0  3.7G   0% /var/lock
/dev/xvdf             100G   19G   82G  19% /db
/dev/xvdg             100G   15G   86G  15% /images
/dev/xvdb             414G  199M  393G   1% /mnt

To me this means all files and directories under /db is on filesystem xvdf, everything under /images is on xvdg and everything under /mnt is on xvdb. Everything else is on xvda1.

However, xvda1 has only 7.9G of space. So why does

/$ sudo du -sh var
25G     var

show me that /var is taking up 25G? I thought at first that maybe it's counting the contents at the destinations of symbolic links but I know a few directories down there's a symbolic link to the /images directory and that's got 86G of content so var should be >86G if symbolic links are followed.

So how can /var take up 25G on a drive that has only 7.9G?

btw, this is an ubuntu instance running in amazon's EC2, if that's significant.

share|improve this question
    
If you run du without -s it will tell you the space each file consumes under /var. sudo du -h /var > /tmp/foo and then look through /tmp/foo. –  Kyle Jones Jun 27 '12 at 17:28
    
possible duplicate of Why is there a discrepancy in disk usage reported by df and du? –  Gilles Jun 27 '12 at 23:13
    
Sparse files is the most likely explanation. Run du /var and check where the big stuff is to see what's going on. –  Gilles Jun 27 '12 at 23:14
add comment

5 Answers

up vote 4 down vote accepted

This will give you proper answer of your trouble.

du -ch --max-depth=1 -x /var

-x will show only data usage of one file-system so skipping other filesystem's content from /var directory

--max-depth=1 will give data usage of only first level e.g. /var/a /var/b and so on

share|improve this answer
    
Yes, this provides values that are much more reasonable. Thanks! –  dl__ Jun 28 '12 at 14:03
add comment

From the output of df,

/dev/xvdg 100G 15G 86G 15% /images

Only 15G were used in the /images.

share|improve this answer
    
Good catch. yes, I looked at the wrong column. So, perhaps du was following symbolic links. –  dl__ Jun 28 '12 at 13:18
1  
Yeah, that is weird, du doesn't following symbolic links by default. Could you check with --no-dereference suggested by Jari Laamanen? –  Derui Si Jun 28 '12 at 14:27
    
I tried it and it had no effect. With or without --no-dereference du reported var using 23G (on a 7.9G drive). The command given by SHW however shows var as using a more believable 480M. –  dl__ Jun 29 '12 at 13:05
add comment

I believe var includes links to other installation directories. du -sh shows the size of all the followed links.

share|improve this answer
    
But not the link to the images directory? for some reason? –  dl__ Jun 27 '12 at 14:48
    
It might be a matter of inode ("hard") versus symbolic ("soft") links. This might help, from (pubs.opengroup.org/onlinepubs/9699919799/utilities/du.html): "By default, when a symbolic link is encountered on the command line or in the file hierarchy, du shall count the size of the symbolic link (rather than the file referenced by the link), and shall not follow the link to another portion of the file hierarchy." –  lonstar Jun 27 '12 at 15:04
2  
Hard links cannot cross file system boundaries, so they are not to blame. You can try to use the parameter --no-dereference for du to force it not to follow any symbolic links. However, I doubt this is the issue, since it is the default already. –  Jari Laamanen Jun 27 '12 at 19:30
    
When I added --no-dereference it had no effect, which is what you'd expect I guess if --no-dereference was the default. –  dl__ Jun 29 '12 at 13:02
add comment

Make sure that var is not a symbolic link to any other file system.

 /$ ls -ld var
 drwxr-xr-x 14 root root 4096 Jun 22 02:13 var
share|improve this answer
add comment

It's also possible that you need to run fsck to fix the discrepancy.

I only mention it for completeness, but I still suspect something else is more likely. Afer a while if you still haven't found anything then you should give this a try.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.