From owner-svn-src-projects@FreeBSD.ORG Wed Jan 26 09:26:27 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF550106566C; Wed, 26 Jan 2011 09:26:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3918FC08; Wed, 26 Jan 2011 09:26:27 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 572FF46B8A; Wed, 26 Jan 2011 04:26:26 -0500 (EST) Date: Wed, 26 Jan 2011 09:26:26 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201101251117.49069.jhb@freebsd.org> Message-ID: References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <201101251117.49069.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-projects@freebsd.org, Alexander Motin , src-committers@freebsd.org Subject: Re: svn commit: r217828 - projects/graid/head/sys/geom/raid X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 09:26:27 -0000 On Tue, 25 Jan 2011, John Baldwin wrote: > Hmm, so this allocates bio's to make the dump work. I believer other dump > routines in other drivers do not do this, but instead use pre-allocated > commands to schedule dump I/O requests. Would it be possible to > pre-allocate the bio that is used here when dumping is enabled and reuse it > for each g_raid_dump() call without free'ing it when the I/O is finished? Yeah, same concern here: memory allocation and freeing in the dump path leads to less robustness. Part of why the existing geom/dump interaction was so simplistic was to avoid exactly this problem by not needing lots of bio allocaiton/replication/etc on the way up/down the stack. Likewise, the goal was to minimise dependence on correct operation of the kernel scheduler. Some storage device drivers are poorly behaved in this regard, but introucing new dependencies in the stack just makes it harder to fix those drivers. (A similar discussion is taking place in the context of network dumping, where it's really important not to introduce further large kernel subsystem dependencies: you want debugging paths to depend on as little in the way of sensitive global data structures, locks, etc, as possible.) Robert