From owner-freebsd-arm@freebsd.org Wed Sep 9 17:13:54 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F00EEA01C04 for ; Wed, 9 Sep 2015 17:13:53 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (smtp61.avvanta.com [206.124.128.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D205F109B for ; Wed, 9 Sep 2015 17:13:53 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (localhost.scooter.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id E6061276D66 for ; Wed, 9 Sep 2015 10:12:46 -0700 (PDT) Received: from MBP16GB.local (c-50-135-203-40.hsd1.wa.comcast.net [50.135.203.40]) by mail.avvanta.com (Postfix) with ESMTP id C7BAD276D62 for ; Wed, 9 Sep 2015 10:12:46 -0700 (PDT) Subject: Re: very odd behaviour from svnlite on RPi2 [FIXED] To: freebsd-arm@freebsd.org References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org> <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> <20150909163516.GB1025@potato.growveg.org> From: kah42pub X-Enigmail-Draft-Status: N1010 Message-ID: <55F068CF.9030707@blarg.com> Date: Wed, 9 Sep 2015 10:13:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150909163516.GB1025@potato.growveg.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.net X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 17:13:54 -0000 On 9/9/15 09:35, John wrote: > On Fri, Sep 04, 2015 at 08:40:17PM -0700, Tim Kientzle wrote: >> >>> On Sep 4, 2015, at 3:32 PM, John wrote: >>> >>> On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: >>> >>>> I got this svn errors from time to time, independently from the rpi. For >>>> getting and updating the ports tree, you can also use the "portsnap" tool >>>> (it's part of the base system). >>> >>> Yeah I thought about doing this instead of svnlite (after I'd started >>> svnlite). >>> After 10 restarts I got so annoyed I made a while loop. I've never used >>> portsnap because I thought it lagged behind svn, but I might use it in >>> future, maybe it's suited more to low-power systems. >> >> Svn should work just fine on "low power systems," but has had problems on >> FreeBSD-based RPi and BeagleBone for a long time. >> >> I suspect the root cause is a bug in SVN when dealing with extremely slow disk: >> I think the TCP connection times out while the svn client is doing a long >> series of disk operations. >> >> It certainly should not be happening. >> >>> I've not seen these errors on the other freebsd boxes in the logs (same >>> connection) which is why I thought it might be a bottleneck with the pi. >> >> In some cases, I've repeated the 'svn cleanup' + 'svn up' cycle for 2-3 days >> before it finally completed only to see missing files that svn doesn't seem to >> be aware of at all. I've found that partial tree checkouts are more likely >> to succeed; you can sometimes work around this by asking SVN to >> checkout/update individual subdirectories. >> >> For FreeBSD source checkouts, I recommend using git which doesn't seem to >> suffer from this problem. Similarly, portsnap is more resilient than svn for >> ports checkouts. > > Hi, > > The workaround for this for me is to take a usb stick, partition it into > four parts and made a 4GB slice for src and 7GB for ports, mounted with > async and noatime, and it's working a treat. The other two partitions I've > set as swap (2GB each) which has fixed the swap issues I described in > another thread. Using the same logic, I might install another stick just for > /usr/obj and /tmp and /var/tmp. It seems the microSD gets a little too > busy if everything is on / > This is the approach I use for my RPIs and RPI2s. The SD cards can't handle the I/O activity of a "real" system so I move various file systems off to a partitioned USB stick. These include: /usr/ports /usr/src /usr/local /home I set noatime on these but haven't been brave enough to set async. Moving these has improved performance and stability on these systems. I have toyed with the idea of moving the following to USB but haven't found a compelling need, yet. Getting the four above off seems to have reduced the stress on the SD card. /tmp /var/tmp /var/log /usr/obj It is possible I'm missing some tuning variable that would make the SD card I/O work better but I couldn't find such a thing and moving the higher use filesystems off to a USB device was definitely a path of least resistance for me. Hope that helps someone. Kris