From owner-freebsd-stable Mon May 13 14:35:44 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 7585A37B400 for ; Mon, 13 May 2002 14:35:38 -0700 (PDT) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id QAA64860; Mon, 13 May 2002 16:35:11 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 13 May 2002 16:35:11 -0500 (CDT) From: Chris Dillon To: Jamie Heckford Cc: dillon@apollo.backplane.com, Subject: Re: NFS Problems with Quantum Snapserver 4100 In-Reply-To: <20020513181756.A53366@mufuf.trident-uk.co.uk> Message-ID: <20020513153536.P53960-100000@mail.wolves.k12.mo.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 13 May 2002, Jamie Heckford wrote: > Im having odd problems with a nfs mount I have which is on a Quantum > Snapserver Model 4100. > > Basically, I have the nfs mount on /data1-home. Small files are > fine, but whenever I try and copy anything fairly "big" (5MB!) the > command prompt just sits there. > > cd'ing to /data1-home just results in the command hanging there, and > the only way to get back to the NFS share is the force an umount and > remount. > > Has anyone had any similar problems? Yes. I have two 400GB 4100's and while things work great, I have come across one situation where I had to ctrl-C out of an 'ls' or 'cd' when trying to list or traverse a certain directory. I use soft + interruptible mounts, and I haven't needed to umount/remount a filesystem to get things working again, just ctrl-C for a while until it gets me back to a prompt. It might time-out after a while, too, but I didn't wait that long. As Matt suggested might be the case, large files aren't a problem: root@cdtech [/root]# mount_nfs -s -i 192.168.254.6:/SHARES /mnt root@cdtech [/root]# cd /mnt/NETAPPS/CDIMAGE root@cdtech [/mnt/NETAPPS/CDIMAGE]# ls -l total 1892624 -rw-r--r-- 1 root wheel 681992192 Apr 16 13:55 CD10D2.ISO -rw-r--r-- 1 root wheel 672856064 Apr 16 14:00 CD10D3.ISO -rw-r--r-- 1 root wheel 582211584 Apr 18 11:17 MSFS98.ISO root@cdtech [/mnt/NETAPPS/CDIMAGE]# dd if=CD10D2.ISO of=/dev/null 1332016+0 records in 1332016+0 records out 681992192 bytes transferred in 119.014340 secs (5730336 bytes/sec) root@cdtech [/mnt/NETAPPS/CDIMAGE]# time cp CD10D2.ISO /dev/null 0.015u 4.050s 1:55.59 3.5% 78+287k 0+0io 1pf+0w As you can see, copying a big file is not a problem, and performance is decent (6MB/sec seems to be about the max from the 4100). The problem occurred only when getting to a certain point in a directory tree and attempting to cd into a directory or ls it. Unfortunately, I'm unable to reproduce the problem right now. I've done a whole 'find . -print' via the mount and everything went fine, and I can't remember exactly where under the rather large tree I had problems the last time. Maybe find won't tickle the bug, maybe it has been fixed in a recent STABLE update, maybe it was fixed when I updated the servers to the latest SnapOS, I don't know. It was such a rare problem that I didn't even worry about it, and it is impossible to say at this time wether FreeBSD was at fault or if it was SnapOS. If I see the problem again, though, I'll bring it up. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message