Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having one nfs volume, which is mounted on one of the directory of root partition. My problem is when I checked df -ha it adds up mounted directory file content as well. Following are my observations, for security reason few names are changed

I am at / right now,

df -ha

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  3.5G  4.1G  47% /
/dev/xvdf             9.9G  183M  9.2G   2% /home/abcedf
                      197G   97G   91G  52% /home/abvdef/pqrstuv

here abcdef is again one mounted volume and pqrstuv is mount point of nfs

you can see right now it is 3.5 gb consumed,

when I execute,

root@ip-10-190-133-49:/# du -sh 
3.5G    .
root@ip-10-190-133-49:/# du -sh --exclude=home
1.3G    .

When I go to /home

root@ip-10-190-133-49:/home# du -sh
2.6G    .
root@ip-10-190-133-49:/home# du -sh --exclude=abcdef
66M     .

when I go to /home/abcdef

root@ip-10-190-133-49:/home/abcdef# du -hs
2.5G    .
root@ip-10-190-133-49:/home/abcdef# du -sh --exclude=pqrstuv
32M     .

Based on above 3 observations I am concluding that my mounted nfs also calculating in df -ha , I want to check is this normal to happen? or I am calculating in wrong manner.

output of alias,

alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'

More details related to this,

when I was on / and run du -shx

root@ip-10-10-221-187:/# du -shx
4.1G    .

and when I run df -ha

root@ip-10-10-221-187:/# df -ha
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  8.2G  1.3G  87% /

Here df says root partition 8.2G occupied, but du calculating only 4.1G, now where the difference 8.2G-4.1G=4.1G is going, it looks like df calculating doubled value, not sure how? and this force me to think is my mounted file system coming into picture in calculation or something else that not coming in my eyes.

Finally I get the issue, See two snaps of top one is before restart and other is after restart,

Before restart when df -ha says I am 8.9G full,

top - 04:36:08 up 5 days, 16:07,  3 users,  load average: 2.34, 2.46, 2.18
Tasks: 225 total,   4 running, 220 sleeping,   0 stopped,   1 zombie
Cpu(s): 19.1%us, 46.0%sy,  0.0%ni, 31.5%id,  3.1%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   7864548k total,  7189196k used,   675352k free,   861072k buffers
Swap:        0k total,        0k used,        0k free,  4221888k cached

After restart when df -ha says I am 5.1G full,

top - 04:39:30 up 0 min,  2 users,  load average: 2.18, 0.65, 0.22
Tasks: 223 total,   4 running, 218 sleeping,   0 stopped,   1 zombie
Cpu(s): 13.6%us, 13.4%sy,  0.0%ni, 39.2%id, 33.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7864548k total,   677452k used,  7187096k free,    15328k buffers
Swap:        0k total,        0k used,        0k free,   150392k cached

Now when I observed cached values then I realize the cached is eating the extra GB that I was not able to find, any suggestion now how can I resolve this ?

share|improve this question

closed as off-topic by Braiam, Michael Homer, jimmij, jasonwryan, Networker Dec 30 '14 at 8:59

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Braiam, Michael Homer, jimmij, jasonwryan, Networker
If this question can be reworded to fit the rules in the help center, please edit the question.

df should not include separate filesystems in the reporting. I started working through your data but it's more work than I can fit in atm - you need to remember in your setup /home is not a filesystem, it's part of /. Also df will report used space on content overmounted, where-as du won't. This isn't an answer, but if you work through each filesystem, unmounting it, checking under it, etc. you'll work out what the real numbers are. Also, please post the output of alias in your question. – EightBitTony Apr 28 '14 at 12:58
@EightBitTony I am not clear with alias part so please provide more information it. Also, your suggestion is good, I will unmount them and re-run the process, but as server is up and running right now, I have to wait for release downtime. – HRK Apr 29 '14 at 7:13
Just type alias and include the output - I'm trying to make sure your du and df commands aren't aliased to some default options. – EightBitTony Apr 29 '14 at 8:25
@EightBitTony see the edit for alias output – HRK Apr 29 '14 at 11:38
I've read this a lot of times, and I still can't understand why you think df is including the NFS share. The NFS share is huge (97G used) and none of your other numbers even come close. – EightBitTony Apr 30 '14 at 10:48

Beware that there are many errors in your analysis. You run du and conclude something about df — no, that doesn't follow. For background, read Why are there so many different ways to measure disk usage?, which discusses du, df and how they differ.

An NFS mount does not affect the space used on the local disk, nor does it affect what df reports for the local disk. If you run du on a tree that includes an NFS mount, then the files on the mounted filesystem are included; pass the -x flag to du to avoid this.

It's difficult to tell exactly what is happening because your reporting is imprecise. You're looking at different machines at different times (different host names, different figures for df), which confuses the matter further. As a matter of methodology, you should:

  • Clearly distinguish between observations and conclusions (especially given that your conclusions are so far-feetched).
  • Use kilobytes rather than approximate units (drop the -h flag), because you can't easily check sums due to the rounding, or tell whether two numbers are really equal (coincidences at a kB level are rarer than at a GB level).

From Why are there so many different ways to measure disk usage?, there are several important considerations which should explain what you're seeing (I'm not sure which ones are relevant to each of your observations because of your imprecise reporting):

  • du does not see files that are hidden behind a mount point (i.e. there are files under /path/to/somewhere and then you mount something on /path/to/somewhere). df does.
  • du does not see deleted files. df does.
  • df on an NFS mount reports a figure from the server; it applies to the whole filesystem on the server side, not just the part that the server is exporting.

Cache is in memory and has absolutely nothing to do with disk space.

share|improve this answer
Absolutely, my observation if from two different servers and both suffering from same problem apologize for that but what I figured out is correct, cache is thing which creating problem of space, stand point is when I executing mentioned command instantly my number starts matching with my flow of testing and also lots of space recovered, I do agree with you that deleting cache is not a proper solution it slow down the processes, but my prime focus is on space outage issue not the performance at least not at this stage. – HRK May 21 '14 at 9:19
@HRK No, I insist, cache is completely unrelated to disk usage. echo 1 > /proc/sys/vm/drop_caches has absolutely no impact on disk usage. Whatever you're seeing, it's not this. – Gilles May 21 '14 at 9:21
OK,I will give it try once again, I will consider your points and edit my base question with proper information. But I have to wait again to that space issue reoccur, so may take time. – HRK May 21 '14 at 9:25

I am able to resolved this by clearing the cache, I have set it up in cron to clear cache periodically.

Following is the command,

sync; echo 1 > /proc/sys/vm/drop_caches

and the article that explain this in detail,


Setting /proc/sys/vm/drop_caches to clear cache

share|improve this answer
Cache has absolutely nothing to do with disk space. The only reason to drop caches is to perform I/O benchmarks, it will never free any disk space, and will not make your system run faster either except in very specific and rather contrived circumstances. – Gilles May 21 '14 at 5:28

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