From owner-svn-src-projects@FreeBSD.ORG Wed Jan 26 09:46:17 2011 Return-Path: <owner-svn-src-projects@FreeBSD.ORG> 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 E762A1065670; Wed, 26 Jan 2011 09:46:16 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1AB48FC0C; Wed, 26 Jan 2011 09:46:15 +0000 (UTC) Received: by bwz12 with SMTP id 12so1227211bwz.13 for <multiple recipients>; Wed, 26 Jan 2011 01:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=aEMvwXMxtuXbQ3uj+3nk569yZ21IpsaSmUGDqXLxD68=; b=neIdcGcwmQsDcK+CclOuoa19blPAlxQ2pBZ4vWVgAp8ymWcKjMuVysX/RAvMUbd25z s+B0+PzVBIrWu029z5oa/pkXkJb73FW1bbA1jp0XOxDXVVpAA4+toiXJoaOE2b1fKsne i6KjxxYd1UKnOHSCjKMLJhDxEHd2Bp3VAAcxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=nh7eeKRGCfmBjEVWBSTvn7acmYUbQR+veA793nVPjgpYcxxX6SqJNKghWgRxDNxWIl q1OCtzVV9AqSBszoonBGdzaYhCrAKP9S+PhzJ/yb87uCeTt6T9+gH4dpMwH/W/ZW7/u6 iq1wIUp8mgPXd4OcoS1BkK5cn1SkHpeeZsAPs= Received: by 10.204.46.130 with SMTP id j2mr163600bkf.169.1296035174435; Wed, 26 Jan 2011 01:46:14 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id v1sm7349349bkt.5.2011.01.26.01.46.11 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 01:46:12 -0800 (PST) Sender: Alexander Motin <mavbsd@gmail.com> Message-ID: <4D3FED31.8040304@FreeBSD.org> Date: Wed, 26 Jan 2011 11:45:21 +0200 From: Alexander Motin <mav@FreeBSD.org> User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Robert Watson <rwatson@FreeBSD.org> References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <201101251117.49069.jhb@freebsd.org> <alpine.BSF.2.00.1101260923140.44308@fledge.watson.org> In-Reply-To: <alpine.BSF.2.00.1101260923140.44308@fledge.watson.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, John Baldwin <jhb@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" <svn-src-projects.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-projects>, <mailto:svn-src-projects-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-projects> List-Post: <mailto:svn-src-projects@freebsd.org> List-Help: <mailto:svn-src-projects-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-projects>, <mailto:svn-src-projects-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 09:46:17 -0000 Robert Watson wrote: > 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.) That's all true. Those who want maximum robustness should use dedicated drive on the most trivial dedicated controller to make dumping reliable. If we are going above that - there are always some compromises. What's about dumping to GEOM, I think that with r217827 change (in projects/graid/head) it should be possible to implement robust dumping to gmirror and gstripe without doing any allocations and GEOM interaction. With some efforts it could also be done to graid by writing specialized minimalistic dumping routines for every transformation module (at least it seems trivial for RAID0/RAID1). -- Alexander Motin