<div dir="ltr"><div>-h will always be different from the actual disk usage, you might also want to play around with -B option too. Honestly though, NFS has never been particularly good with stuff like this.</div><div><br></div>
What happens when you use --apparent-size option.<div><div> --apparent-size</div><div> print apparent sizes, rather than disk usage; although the</div><div> apparent size is usually smaller, it may be larger due to holes</div>
<div> in ('sparse') files, internal fragmentation, indirect blocks,</div><div> and the like</div></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 3:40 PM, Mike Miller <span dir="ltr"><<a href="mailto:mbmiller+l@gmail.com" target="_blank">mbmiller+l@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I thought this issue was caused by a bug in the GNU du code, and I'm still not sure that it isn't, but it might be caused by bugs in file systems or NFS. I'm using this version of du:<br>
<br>
$ du --version<br>
du (GNU coreutils) 8.4<br>
Copyright (C) 2010 Free Software Foundation, Inc.<br>
<br>
I'm using one of the MSI supercomputers. The /project/guanwh directory is NFS mounted. Here's the kind of thing I'm seeing:<br>
<br>
$ du -sh /project/guanwh/miller/CHoP/<u></u>intensity/<br>
41G /project/guanwh/miller/CHoP/<u></u>intensity/<br>
<br>
$ du -sm /project/guanwh/miller/CHoP/<u></u>intensity/<br>
41171 /project/guanwh/miller/CHoP/<u></u>intensity/<br>
<br>
$ du -sb /project/guanwh/miller/CHoP/<u></u>intensity/<br>
65435522887 /project/guanwh/miller/CHoP/<u></u>intensity/<br>
<br>
$ du -sm /project/guanwh/miller/CHoP/<u></u>intensity/<br>
41299 /project/guanwh/miller/CHoP/<u></u>intensity/<br>
<br>
$ du -sh /project/guanwh/miller/CHoP/<u></u>intensity/<br>
41G /project/guanwh/miller/CHoP/<u></u>intensity/<br>
<br>
Those commands were run seconds apart while a file transfer was increasing the amount of disk used.<br>
<br>
What you are seeing is that the result with -b (bytes) is correct, or at least nearly so, while the results with -m and -h are off by many gigabytes. I am in the process of transferring files into that directory, but I don't see why options -m, -h and -b should give wildly different numbers!<br>
<br>
I'm wondering if the problem I'm having has to do with NFS mounting. There is a known issue:<br>
<br>
<a href="https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html" target="_blank">https://www.gnu.org/software/<u></u>coreutils/manual/html_node/du-<u></u>invocation.html</a><br>
<br>
"On BSD systems, du reports sizes that are half the correct values for files that are NFS-mounted from HP-UX systems. On HP-UX systems, it reports sizes that are twice the correct values for files that are NFS-mounted from BSD systems. This is due to a flaw in HP-UX; it also affects the HP-UX du program."<br>
<br>
I am seeing usage with -sb that is 50% larger than that with -sB KB (or -sB MB or -sB GB).<br>
<br>
For me, the message is to use -sb instead of -sh. The latter gives a nice compact result, but it is probably reading numbers of file blocks and those can have different meanings and cause different results.<br>
<br>
Mike<br>
______________________________<u></u>_________________<br>
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>
<a href="mailto:tclug-list@mn-linux.org" target="_blank">tclug-list@mn-linux.org</a><br>
<a href="http://mailman.mn-linux.org/mailman/listinfo/tclug-list" target="_blank">http://mailman.mn-linux.org/<u></u>mailman/listinfo/tclug-list</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Ben Lutgens<br>Linux / Unix System Administrator<br><br>Three of your friends throw up after eating chicken salad. Do you think:<br>"I should find more robust friends" or "we should check that refrigerator"?<br>
-- Donald Becker, on vortex-bug, suspecting a network-wide problem<br>
</div>