I'm seeing some very dodgy behaviour in my home NFS environment. I have a 4.7-RC2 box serving up /export, and this machine is called 'thefather'. I have my laptop, 5.0-CURRENT (a day or two stale), and this machine is called 'luna'. I also have a 4.7-STABLE (a week or two stale) box, called 'dalek'.
Now, I have a mount of thefather:/export on /mnt on luna, and the mount is there, and gtk-gnutella is running with its download directory in /mnt/@shared/download, and so on. Gtk-Gnutella is still running and downloading files fine. However if I try to df -h or ls -lart / or ls /mnt/@shared/unsorted, the process in question will block indefinitely in the NFS lock recv code, but yet if I ssh to dalek and try to do the same, it works fine and dandy. Note that this problem just appeared about 20 minutes ago, and is still occurring, and I've had it happen before... Anyone seen this or have any clue? I'm vaguely familiar with the lock stuff in nfs_socket.c on the client side, but I've still got no idea what is going on... Could it be because I'm using TCP nfs, rather than UDP, and that somehow affects statep for multiple concurrent requests? Thanks, juli. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
