From owner-freebsd-stable@FreeBSD.ORG Tue Jul 5 07:00:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E63E106566B for ; Tue, 5 Jul 2011 07:00:26 +0000 (UTC) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8215A8FC0A for ; Tue, 5 Jul 2011 07:00:25 +0000 (UTC) X-Envelope-From: Peter.Ross@bogen.in-berlin.de Received: from localhost (okapi.in-berlin.de [192.109.42.117]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id p6570Nr7017139; Tue, 5 Jul 2011 09:00:23 +0200 Received: from 124-254-118-24-static.bb.ispone.net.au (124-254-118-24-static.bb.ispone.net.au [124.254.118.24]) by webmail.in-berlin.de (Horde Framework) with HTTP; Tue, 05 Jul 2011 17:00:23 +1000 Message-ID: <20110705170023.87183xz6ehxbeft3@webmail.in-berlin.de> Date: Tue, 05 Jul 2011 17:00:23 +1000 From: "Peter Ross" To: "freebsd-stable List" References: <20110701222232.GA33935@icarus.home.lan> <20110702045435.GA81502@DataIX.net> <54D65EC5-9A9B-4F96-BB45-1904F2147CBA@gmail.com> <20110704100845.94513n3znbabpthp@webmail.in-berlin.de> In-Reply-To: <20110704100845.94513n3znbabpthp@webmail.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: Scott Sipe , Jeremy Chadwick Subject: Re: scp: Write Failed: Cannot allocate memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 07:00:26 -0000 Hi all, just as an addition: an upgrade to last Friday's FreeBSD-Stable and to =20 VirtualBox 4.0.8 does not fix the problem. I will experiment a bit more tomorrow after hours and grab some statistics. Regards Peter Quoting "Peter Ross" : > Hi all, > > I noticed a similar problem last week. It is also very similar to =20 > one reported last year: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.ht= ml > > My server is a Dell T410 server with the same bge card (the same =20 > pciconf -lvc output as described by Mahlon: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058711.ht= ml > > Yours, Scott, is a em(4).. > > Another similarity: In all cases we are using VirtualBox. I just =20 > want to mention it, in case it matters. I am still running =20 > VirtualBox 3.2. > > Most of the time kstat.zfs.misc.arcstats.size was reaching =20 > vfs.zfs.arc_max then, but I could catch one or two cases then the =20 > value was still below. > > I added vfs.zfs.prefetch_disable=3D1 to sysctl.conf but it does not help. > > BTW: It looks as ARC only gives back the memory when I destroy the =20 > ZFS (a cloned snapshot containing virtual machines). Even if nothing =20 > happens for hours the buffer isn't released.. > > My machine was still running 8.2-PRERELEASE so I am upgrading. > > I am happy to give information gathered on old/new kernel if it helps. > > Regards > Peter > > Quoting "Scott Sipe" : > >> >> On Jul 2, 2011, at 12:54 AM, jhell wrote: >> >>> On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote: >>>> On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote: >>>>> I'm running 8.2-RELEASE and am having new problems with scp. When scpi= ng >>>>> files to a ZFS directory on the FreeBSD server -- most notably =20 >>>>> large files >>>>> -- the transfer frequently dies after just a few seconds. In my =20 >>>>> last test, I >>>>> tried to scp an 800mb file to the FreeBSD system and the =20 >>>>> transfer died after >>>>> 200mb. It completely copied the next 4 times I tried, and then =20 >>>>> died again on >>>>> the next attempt. >>>>> >>>>> On the client side: >>>>> >>>>> "Connection to home closed by remote host. >>>>> lost connection" >>>>> >>>>> In /var/log/auth.log: >>>>> >>>>> Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot alloc= ate >>>>> memory >>>>> >>>>> I've never seen this before and have used scp before to transfer =20 >>>>> large files >>>>> without problems. This computer has been used in production for =20 >>>>> months and >>>>> has a current uptime of 36 days. I have not been able to notice =20 >>>>> any problems >>>>> copying files to the server via samba or netatalk, or any problems in >>>>> apache. >>>>> >>>>> Uname: >>>>> >>>>> FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 E= ST >>>>> 2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64 >>>>> >>>>> I've attached my dmesg and output of vmstat -z. >>>>> >>>>> I have not restarted the sshd daemon or rebooted the computer. >>>>> >>>>> Am glad to provide any other information or test anything else. >>>>> >>>>> {snip vmstat -z and dmesg} >>>> >>>> You didn't provide details about your networking setup (rc.conf, >>>> ifconfig -a, etc.). netstat -m would be useful too. >>>> >>>> Next, please see this thread circa September 2010, titled "Network >>>> memory allocation failures": >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread= .html#58708 >>>> >>>> The user in that thread is using rsync, which relies on scp by default. >>>> I believe this problem is similar, if not identical, to yours. >>>> >>> >>> Please also provide your output of ( /usr/bin/limits -a ) for the server >>> end and the client. >>> >>> I am not quite sure I agree with the need for ifconfig -a but some >>> information about the networking driver your using for the interface >>> would be helpful, uptime of the boxes. And configuration of the pool. >>> e.g. ( zpool status -a ;zfs get all ) You should probably >>> prop this information up somewhere so you can reference by URL whenever >>> needed. >>> >>> rsync(1) does not rely on scp(1) whatsoever but rsync(1) can be made to >>> use ssh(1) instead of rsh(1) and I believe that is what Jeremy is >>> stating here but correct me if I am wrong. It does use ssh(1) by >>> default. >>> >>> Its a possiblity as well that if using tmpfs(5) or mdmfs(8) for /tmp >>> type filesystems that rsync(1) may be just filling up your temp ram area >>> and causing the connection abort which would be expected. ( df -h ) woul= d >>> help here. >> >> Hello, >> >> I'm not using tmpfs/mdmfs at all. The clients yesterday were 3 =20 >> different OSX computers (over gigabit). The FreeBSD server has 12gb =20 >> of ram and no bce adapter. For what it's worth, the server is =20 >> backed up remotely every night with rsync (remote FreeBSD uses =20 >> rsync to pull) to an offsite (slow cable connection) FreeBSD =20 >> computer, and I have not seen any errors in the nightly rsync. >> >> Sorry for the omission of networking info, here's the output of the =20 >> requested commands and some that popped up in the other thread: >> >> http://www.cap-press.com/misc/ >> >> In rc.conf: ifconfig_em1=3D"inet 10.1.1.1 netmask 255.255.0.0" >> >> Scott >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >