Date: Wed, 9 Sep 2015 10:13:51 -0700 From: kah42pub <kah42pub@blarg.com> To: freebsd-arm@freebsd.org Subject: Re: very odd behaviour from svnlite on RPi2 [FIXED] Message-ID: <55F068CF.9030707@blarg.com> In-Reply-To: <20150909163516.GB1025@potato.growveg.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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 / > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F068CF.9030707>