On Mon, 8 May 2006, Mike Marion wrote: > On Fri, May 05, 2006 at 09:59:14AM +0800, Ian Kent wrote: > > > I think that might be the other way around. > > You mean rpciod is already hung before the umount, and the umount is > then hung due to the rpciod?
My mistake. We don't actually know which way around it is. > > > > /bin/umount //usr/local/projects/dsp/qdsp6 > > > > > > root 6270 0.0 0.0 0 0 ? D Apr28 3:17 [rpciod] > > > > > > unfortunately, once this happens, any new mounts will fail. Can't even > > > stat the path above via df. Basically the whole NFS layer is stuck. > > > > Tell us what the maps look like. > > The noted path is like this: > /prj/dsp/qdsp6 > -rw,acdirmin=1,acdirmax=5,acregmin=1,acregmax=5,rsize=32768,wsize=32768,noquota > western:/vol/eng_aus_0004/qdsp6 > > And the rest of the file is very similar. The huge amount of options > came from trial and error with performance problems we were having, and > they're defaulting to tcp mounts. The odd thing is that we basically > never have mounts hanging off this /prj tree in San Diego, or any other > office except for one. And it's only hanging when talking to their 2 > local NetApp filers. This problem does appear a bit like an NFS problem. Have you checked the versions for each of the subsystems involved and compared working and not working? Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
