<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Saw your post it's a bit deep for me but this might help.<br><br>Sorry if I am out of place here.<br><br>http://www.cyberciti.biz/tips/nfs-stale-file-handle-error-and-solution.html<br><br><h3>How do I fix this problem?</h3>a) The best solution is to remount directory from the NFS client using <a href="http://www.cyberciti.biz/tips/ubuntu-linux-nfs-client-configuration-to-mount-nfs-share.html">mount command</a>:<br> <code># <a href="http://www.cyberciti.biz/tips/how-do-i-forcefully-unmount-a-disk-partition.html">umount -f /mnt/local</a><br> # mount -t nfs nfsserver:/path/to/share /mnt/local</code><BR>First <a href="http://www.cyberciti.biz/tips/how-do-i-forcefully-unmount-a-disk-partition.html">command</a> (umount) forcefully unmount a disk partition /mnt/local (NFS).<BR><br><BR>Thanks, paul g<br><BR><br><br><div>> Date: Tue, 1 Apr 2014 21:14:02 -0500<br>> From: mbmiller+l@gmail.com<br>> To: tclug-list@mn-linux.org<br>> Subject: Re: [tclug-list] interesting "feature" of the GNU du command<br>> <br>> On Tue, 1 Apr 2014, Ben wrote:<br>> <br>> > -h will always be different from the actual disk usage, you might also <br>> > want to play around with -B option too.<br>> <br>> I've done that. Using --si -sB GB gives the same result as --si -sh. <br>> Did you think that they would be different?<br>> <br>> <br>> > Honestly though, NFS has never been particularly good with stuff like <br>> > this.<br>> <br>> Well, there is the HP bug reported in the du info page, and recapped <br>> below, but are there other problems?<br>> <br>> <br>> > What happens when you use --apparent-size option.<br>> > --apparent-size<br>> > print apparent sizes, rather than disk usage; although the<br>> > apparent size is usually smaller, it may be larger due to holes<br>> > in ('sparse') files, internal fragmentation, indirect blocks,<br>> > and the like<br>> <br>> I want to try that, but I'm having this problem right now:<br>> <br>> $ ls /project/guanwh<br>> ls: cannot access /project/guanwh: Stale file handle<br>> <br>> I tried logging out and logging back in, but that didn't help. They might <br>> be working on the issue after I reported it. If it had been something <br>> simple, they probably would have told me by now.<br>> <br>> Mike<br>> <br>> <br>> > On Tue, Apr 1, 2014 at 3:40 PM, Mike Miller <mbmiller+l@gmail.com> wrote:<br>> ><br>> >> I thought this issue was caused by a bug in the GNU du code, and I'm still<br>> >> not sure that it isn't, but it might be caused by bugs in file systems or<br>> >> 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<br>> >> NFS mounted. Here's the kind of thing I'm seeing:<br>> >><br>> >> $ du -sh /project/guanwh/miller/CHoP/intensity/<br>> >> 41G /project/guanwh/miller/CHoP/intensity/<br>> >><br>> >> $ du -sm /project/guanwh/miller/CHoP/intensity/<br>> >> 41171 /project/guanwh/miller/CHoP/intensity/<br>> >><br>> >> $ du -sb /project/guanwh/miller/CHoP/intensity/<br>> >> 65435522887 /project/guanwh/miller/CHoP/intensity/<br>> >><br>> >> $ du -sm /project/guanwh/miller/CHoP/intensity/<br>> >> 41299 /project/guanwh/miller/CHoP/intensity/<br>> >><br>> >> $ du -sh /project/guanwh/miller/CHoP/intensity/<br>> >> 41G /project/guanwh/miller/CHoP/intensity/<br>> >><br>> >> Those commands were run seconds apart while a file transfer was increasing<br>> >> the amount of disk used.<br>> >><br>> >> What you are seeing is that the result with -b (bytes) is correct, or at<br>> >> least nearly so, while the results with -m and -h are off by many<br>> >> gigabytes. I am in the process of transferring files into that directory,<br>> >> but I don't see why options -m, -h and -b should give wildly different<br>> >> numbers!<br>> >><br>> >> I'm wondering if the problem I'm having has to do with NFS mounting. There<br>> >> is a known issue:<br>> >><br>> >> https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html<br>> >><br>> >> "On BSD systems, du reports sizes that are half the correct values for<br>> >> files that are NFS-mounted from HP-UX systems. On HP-UX systems, it reports<br>> >> sizes that are twice the correct values for files that are NFS-mounted from<br>> >> BSD systems. This is due to a flaw in HP-UX; it also affects the HP-UX du<br>> >> program."<br>> >><br>> >> I am seeing usage with -sb that is 50% larger than that with -sB KB (or<br>> >> -sB MB or -sB GB).<br>> >><br>> >> For me, the message is to use -sb instead of -sh. The latter gives a nice<br>> >> compact result, but it is probably reading numbers of file blocks and those<br>> >> can have different meanings and cause different results.<br>> >><br>> >> Mike<br>> >> _______________________________________________<br>> >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>> >> tclug-list@mn-linux.org<br>> >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list<br>> >><br>> ><br>> ><br>> ><br>> > -- <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>> ><br>> _______________________________________________<br>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>> tclug-list@mn-linux.org<br>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list<br></div> </div></body>
</html>