Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Apr 2004 02:20:54 -0800
From:      Sean McNeil <sean@mcneil.com>
To:        freebsd-current@freebsd.org
Subject:   Re: nfs server issues - more info
Message-ID:  <1080901254.84796.45.camel@server.mcneil.com>
In-Reply-To: <1080882894.5980.26.camel@server.mcneil.com>
References:  <1080882894.5980.26.camel@server.mcneil.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-04-01 at 21:14, Sean McNeil wrote:
> I have googled and seen a great deal of talk about FreeBSD nfs client
> issues, but haven't seen anything about server problems.  I've now tried
> with a Solaris 2.7, HPUX 11.11, and 2 different Linux boxes and I get
> the same thing happening...
> 
> If I mount an nfs partition on any of the above mentioned machines,
> everything works fine until I try to copy a bunch of files over.  For
> instance, if I mount it at /mnt and do
> 
> cd /localdisk; (cd /mnt; tar cf - .) | tar xvf -
> 
> It will lock up hard.  Linux is saying
> 
> nfs: task xxxx can't get a request slot
> 
> It is only the one mount point that is effected, though.  The same
> machine is serving accounts from ldap and is providing /home.  All that
> still works!

This has to be related to reading a directory.  I have narrowed it down
to two distinct directories for HPUX and Linux.  Both are in the cvs
tree of binutils.

For HPUX, it hangs on binutils/gdb/rdi-share.  It doesn't matter where I
place this directory.  I've deleted it, cvs up'd it, copied it with tar,
renamed the directory. Nothing worked.  Then, I deleted a file from the
directory and bingo! It worked!  Put the file back and same old problem.

For Linux, it hangs on binutils/dejagnu.  Again, doesn't matter where
the directory is it acts just like HPUX in this regard.  Same thing if I
delete a file in there too.  Works like a charm.  Put the file back, it
hangs.

It is not the size of the directory file that matters.  I've looked for
directories of the same size for both HPUX and Linux.  I found exact
sizes that work fine.  It has to be the contents of the directories
themselves.

Since it doesn't matter where I place these directories and the sources
are freely available, I have made an archive and placed it at

www.mcneil.com/~sean/rdi-share.tar.gz

This is what fails on:
HP-UX pcurve2 B.11.11 U 9000/785 2013759399 unlimited-user license
It is 150904 bytes.

www.mcneil.com/~sean/dejagnu.tar.gz

This is what fails on Linux:
Linux debian 2.4.18-k6 #1 Sun Apr 14 12:43:22 EST 2002 i686 unknown
It is 1227108 bytes.  The stock debian kernel from an install also
failed.  Do not know if it was on this directory (sorry), but I had the
same type of issues.

I have an embedded PPC development board running Linux as well:
Linux 192.168.10.45 2.4.18_mvl30-405ep_eval #1 Wed Sep 10 14:23:02 EDT
2003 ppc ppc ppc GNU/Linux
It is not failing on the dejagnu directory like the x86 is.  I have had
it fail on me, though, and it is what actually started my whole
investigation.  I don't have a network terminal server on it, so it's
output is limited to 9600 baud.  I'm doing an ls -lR to see what
directory this one fails in.  Taking forever.

My Solaris box:
SunOS wrsparc.mcneil.com 5.7 Generic_106541-12 sun4u sparc
SUNW,Ultra-5_10
Did not hang at all on the ls -lR.  I am confused now if it ever had a
problem.  I don't use it very often.  Trying out some things to see if I
can get it to fail, but so far it looks good.

Cheers,
Sean




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1080901254.84796.45.camel>