Saw your post it's a bit deep for me but this might help.

Sorry if I am out of place here.

http://www.cyberciti.biz/tips/nfs-stale-file-handle-error-and-solution.html

How do I fix this problem?a) The best solution is to remount directory from the NFS client using mount command:
 # umount -f /mnt/local
 #  mount -t nfs nfsserver:/path/to/share /mnt/local
First command (umount) forcefully unmount a disk partition /mnt/local (NFS).


Thanks, paul g



> Date: Tue, 1 Apr 2014 21:14:02 -0500
> From: mbmiller+l at gmail.com
> To: tclug-list at mn-linux.org
> Subject: Re: [tclug-list] interesting "feature" of the GNU du command
> 
> On Tue, 1 Apr 2014, Ben wrote:
> 
> > -h will always be different from the actual disk usage, you might also 
> > want to play around with -B option too.
> 
> I've done that.  Using --si -sB GB gives the same result as --si -sh. 
> Did you think that they would be different?
> 
> 
> > Honestly though, NFS has never been particularly good with stuff like 
> > this.
> 
> Well, there is the HP bug reported in the du info page, and recapped 
> below, but are there other problems?
> 
> 
> > What happens when you use --apparent-size option.
> > --apparent-size
> >   print apparent sizes,  rather  than  disk  usage;  although the
> >   apparent  size is usually smaller, it may be larger due to holes
> >   in ('sparse') files, internal  fragmentation,  indirect blocks,
> >   and the like
> 
> I want to try that, but I'm having this problem right now:
> 
> $ ls /project/guanwh
> ls: cannot access /project/guanwh: Stale file handle
> 
> I tried logging out and logging back in, but that didn't help. They might 
> be working on the issue after I reported it.  If it had been something 
> simple, they probably would have told me by now.
> 
> Mike
> 
> 
> > On Tue, Apr 1, 2014 at 3:40 PM, Mike Miller <mbmiller+l at gmail.com> wrote:
> >
> >> 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:
> >>
> >> $ du --version
> >> du (GNU coreutils) 8.4
> >> Copyright (C) 2010 Free Software Foundation, Inc.
> >>
> >> I'm using one of the MSI supercomputers.  The /project/guanwh directory is
> >> NFS mounted.  Here's the kind of thing I'm seeing:
> >>
> >> $ du -sh /project/guanwh/miller/CHoP/intensity/
> >> 41G     /project/guanwh/miller/CHoP/intensity/
> >>
> >> $ du -sm /project/guanwh/miller/CHoP/intensity/
> >> 41171   /project/guanwh/miller/CHoP/intensity/
> >>
> >> $ du -sb /project/guanwh/miller/CHoP/intensity/
> >> 65435522887     /project/guanwh/miller/CHoP/intensity/
> >>
> >> $ du -sm /project/guanwh/miller/CHoP/intensity/
> >> 41299   /project/guanwh/miller/CHoP/intensity/
> >>
> >> $ du -sh /project/guanwh/miller/CHoP/intensity/
> >> 41G     /project/guanwh/miller/CHoP/intensity/
> >>
> >> Those commands were run seconds apart while a file transfer was increasing
> >> the amount of disk used.
> >>
> >> 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!
> >>
> >> I'm wondering if the problem I'm having has to do with NFS mounting. There
> >> is a known issue:
> >>
> >> https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html
> >>
> >> "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."
> >>
> >> I am seeing usage with -sb that is 50% larger than that with -sB KB (or
> >> -sB MB or -sB GB).
> >>
> >> 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.
> >>
> >> Mike
> >> _______________________________________________
> >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> >> tclug-list at mn-linux.org
> >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
> >>
> >
> >
> >
> > -- 
> > Ben Lutgens
> > Linux / Unix System Administrator
> >
> > Three of your friends throw up after eating chicken salad.  Do you think:
> > "I should find more robust friends" or "we should check that refrigerator"?
> >       -- Donald Becker, on vortex-bug, suspecting a network-wide problem
> >
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140401/92d4de3b/attachment-0001.html>