From owner-freebsd-current@freebsd.org Wed Mar 7 17:43:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF410F44059; Wed, 7 Mar 2018 17:43:37 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77A1183AB2; Wed, 7 Mar 2018 17:43:37 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C32F320D4A; Wed, 7 Mar 2018 12:43:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 07 Mar 2018 12:43:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=6B2C3TIbVTffR3XnCzbOLfgGbejfPlXdHV7sEpjB34I=; b=RMnN0EXd wZWBvyq5v2xlTfOSpJGrOHXavvjVtsOgayuhV5KWpLtRvstbHzPz0qmNbId6b5cQ s1JnrZQ1kzyKMQgHm9F9qZmQINFsURIHZga7eMQm7HnICyvF2l+rlsRPwoJ41djl RitlPXwVC+NBNkC+SyhvAb5/1GYZTjt5V4XxiFD4V1/cq6T6A+puAH+Glrk2N9XJ aEx0DAOOzt5pYwKXKqYibXfTITgNWXsYKhpidcek4sVC7KKajjWScB0MGKICxhD8 2yM5rfewQuLDm3BolSDdOKWOpP7fRNudIqHV8ILAJK5/0tMQL2KuVptxsrJKdJRU bmfQEIyop5v05Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=6B2C3TIbVTffR3XnCzbOLfgGbejfP lXdHV7sEpjB34I=; b=GOV9wJr2NiXg1nFZ68wBFu9KyyZGuFGaKrgWkPrFBehXP LhF1kPRppFj99/Uz4HLAb/SXIqAgzgFxuK5nPyjQQl2kE7EaJC6wwh28QFQXfNqS 7+gX9QSeqg+/u2dEO7qnclWHieaHYUqU/wVfAMm4mXtmMDjDB/AX3d/oLTvD78WN Yf0WzkEUD4z3RToc55hS5ntdZwV3e2t+0iqczy+p9v+ACGTH7NiCHy/YyzFtA+hR xlZkopzgv9FAV776JnJtRaUqKtrHKzXCbCmCRLgvzNKCfC3V7B8wmPvYpnKVGTxY RLmmVh/4C1rnL7zdxIrrplygiMIUZNX0uYagpdxbw== X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 27C79246D5; Wed, 7 Mar 2018 12:43:36 -0500 (EST) To: freebsd-fs Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org From: tech-lists Subject: updating via svn and usb2 thumbdrives Message-ID: <5f3f4e06-c72f-0384-a428-823a30810368@zyxst.net> Date: Wed, 7 Mar 2018 17:43:35 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 17:43:38 -0000 Hi, When updating, particularly when downloading the src or ports tree for the first time, even though I've taken all approaches possible to speed up access to attached usb2 drives, I'll get these errors which will cause the update to bail: A ports/www/py-django-otp svn: E120106: ra_serf: The server sent a truncated HTTP response body. where it'll remain until I restart it but sometimes it'll crash so badly svn will demand svn cleanup on the dir I'm downloading to, like this: A ports/www/elgg/files svn: E120106: ra_serf: The server sent a truncated HTTP response body. # svnlite co https://svn0.eu.FreeBSD.org/ports/head /ext/ports svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '/ext/ports' locked. svn: E155004: '/ext/ports' is already locked. So I do this: # svnlite cleanup /ext/ports ...and I can start svnlite again. I'm sure this has to do with the thumbdrive 'catching up' with writing. So my question is this: Is there some switch in svnlite or some tool or parameter I can give to the process that will either buffer or limit the demands made of the device? It's UFS2 mounted with -o async[might be redundant],rw and has soft-updates but no journalling. My connection speed is 23Mbit so I'm thinking that on usb2 this might be approaching its random write speed but i'm unsure. What's the best way to permanently fix this? thanks, -- J.