On Fri, 6 Mar 2015 08:27:03 +1100 Cameron Simpson wrote: I was yesterday, but today the strace'ed version hung as well and I was able to find and unmount some slow filesystems. I don't know why "df -l" even stat()s an NFS mountpoint at all, it could certainly look at /proc/mounts and find the local only filesystems and utterly ignore the network systems, but it apparently doesn't do that (because I certainly see the stat calls when I strace it). Judging from the strace it gathers all the info first, then formats it for output, so when it hangs, it prints nothing.

On 04Mar2015 18:27, Rick Stevens <ricks(a)alldigital.com&gt; wrote: "Walks"? This is df, not du. Consult mount table, do fstats. [...] I'm fairly certain that strace does not work that way. The traced process is not doing work for the tracer. I think so too. Tom: - _after_ a fast straced df, is un unstraced df slow again? (thinking about cached answers to call, caches in the OS, possibly quite briefly) - see if the result of strace's -T option is informative. - since df's output is line buffered on a terminal, the presentation of the lines should tell you where it is hanging. df makes pleasingly few system calls on a handy RHEL5 host. It opens /etc/mtab and essentially just calls statfs() on each name. This implies that determining localness is done based entirely on the contents of /etc/mtab. Also, this shows that there are no other system calls between the write() reporting the prior filesystem and the statfs() inquiring about the next, so watching an unstraced on-a-terminal df should pinpoint the place of stallness. Is it similar on your fedora box? Cheers, Cameron Simpson <cs(a)zip.com.au&gt; Against stupidity....the Gods themselves contend in vain!

On 03/04/2015 05:01 PM, Tom Horsley wrote: Methinks the "df -l" still walks down non-local filesystems but limits the _display_ to local systems. I haven't tried it, but that may be what it's doing. Odds are that while df is traversing one of those NFS beasties, it is in a "D" state (verifiable by running top and looking at it). If so, it's waiting for some sort of signal (generally "I/O Complete" which may never come if the NFS server isn't answering the bell). Since strace requires it to report what it's doing, it's getting interrupted a lot, so it doesn't hang. I mean, it's still waiting on the I/O to complete from NFS, but rather than waiting an interminate time, it's getting interrupts (signals) from strace rather than hanging on the one from the NFS system. Just a wild guess. I stay out of rabbit holes (I'm claustrophobic). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If the enemy's in range...so are you! - ----------------------------------------------------------------------