Date: Wed, 9 Sep 2015 17:35:16 +0100 From: John <freebsd-lists@potato.growveg.org> To: freebsd-arm@freebsd.org Subject: Re: very odd behaviour from svnlite on RPi2 [FIXED] Message-ID: <20150909163516.GB1025@potato.growveg.org> In-Reply-To: <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org> <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 04, 2015 at 08:40:17PM -0700, Tim Kientzle wrote: > > > On Sep 4, 2015, at 3:32 PM, John <freebsd-lists@potato.growveg.org> 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 / -- John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150909163516.GB1025>