From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 10:25:13 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE22E106566C for ; Mon, 12 Jan 2009 10:25:13 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9151E8FC18 for ; Mon, 12 Jan 2009 10:25:13 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-240-125.phil.east.verizon.net [70.20.240.125]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 83F905FEC1; Mon, 12 Jan 2009 19:07:11 +0900 (JST) Date: Mon, 12 Jan 2009 05:05:37 -0500 From: Yoshihiro Ota To: Peter Jeremy Message-Id: <20090112050537.f423215c.ota@j.email.ne.jp> In-Reply-To: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 3x read to write ratio on dump/restore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 10:25:14 -0000 Jermey, I tought you wrote this, http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html. Try GEOM Cache(gcache). It will be like, $ gcache create temp -s /dev/XXYsZ $ dump /dev/cache/temp <...> It's been 9 months since I tested so I don't remember about the detail numbers. However, I think it reduced user-time with dump to a half. I only wish gcache creates devices with .cache suffix like /dev/XXYsZ.cache. The cache cannot be shared among other providers anyway, it looks suffix style is more appropriate. Regards, Hiro On Sun, 11 Jan 2009 15:17:10 +1100 Peter Jeremy wrote: > On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: > >The read kBps was 3x the write kBps. > ... > >Any ideas what gives? I observed this with 16MB cache and with 32MB > >cache, fwiw. > > I've seen this as well. AFAIK, this is a side-effect of dump's caching. > > My top-of-head explanation is that each dump process has its own cache > but actual I/O is round-robined on a (roughly) block scale so a large > contiguous file will wind up in each 'slave' process's cache. > > The most obvious (and easiest) fixes are to either implement a shared > cache (though this means another level of inter-process communication) > or only use a single 'slave' process when caching is enabled. > > The cache algorithm could probably be enhanced as well - apart from > inode blocks, any block will only be accessed once so once a block has > been accessed, it can be purged from the cache (which is completely > opposite to a "normal" cache). > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. >