From owner-svn-src-projects@FreeBSD.ORG Tue Jan 25 17:45:25 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 B38E71065693; Tue, 25 Jan 2011 17:45:25 +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 D41DB8FC13; Tue, 25 Jan 2011 17:45:24 +0000 (UTC) Received: by bwz12 with SMTP id 12so584503bwz.13 for ; Tue, 25 Jan 2011 09:45:23 -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:content-type :content-transfer-encoding; bh=2ifOh5WsF2RqFDbNtK6+1/zlEC5I+P86llTXUM74lmc=; b=COhLH37SQYTI7uj0QhYSPT8LJ/iZXWa/kvj6HMTGrX1lQ78cCAokWgQiXn1sKRchkn ZxlYsdAre7SAA0nOdhSmAn/1HxK7CyKAMOciV1adhwHFBhflX/rdOWj/dNLF/mO/AWjb 1YtSZWlI+g7D+e4RWsF1jwWRM+uh2zUm+2Ysc= 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:content-type:content-transfer-encoding; b=sPyp3VpoxgKyokWHcWw198vQs8ET8TYyT7bRD90zm/k+zcJKA+vCOxbMu5AJas2GEb 3/uYNu55l8QkHD7sDJiCnk+bLWHX9h5Fptj/l8YGNRBdFldTNHoa6vl5glnIhHROGwyC SxpcY58xcFCUcGGhvG0fkbiVbAETBHYr+R6CI= Received: by 10.204.76.65 with SMTP id b1mr5347596bkk.29.1295977502441; Tue, 25 Jan 2011 09:45:02 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id z18sm4768523bkf.8.2011.01.25.09.44.59 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 09:45:00 -0800 (PST) Sender: Alexander Motin Message-ID: <4D3F0C13.6020902@FreeBSD.org> Date: Tue, 25 Jan 2011 19:44:51 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <201101251117.49069.jhb@freebsd.org> <4D3EFB3F.8020508@FreeBSD.org> <201101251207.13859.jhb@freebsd.org> In-Reply-To: <201101251207.13859.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, 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: Tue, 25 Jan 2011 17:45:25 -0000 On 25.01.2011 19:07, John Baldwin wrote: > On Tuesday, January 25, 2011 11:33:03 am Alexander Motin wrote: >> On 25.01.2011 18:17, John Baldwin wrote: >>> On Tuesday, January 25, 2011 10:34:07 am Alexander Motin wrote: >>>> Author: mav >>>> Date: Tue Jan 25 15:34:07 2011 >>>> New Revision: 217828 >>>> URL: http://svn.freebsd.org/changeset/base/217828 >>>> >>>> Log: >>>> Implement kernel dumping to geom_raid volumes. Dumping mechanism supports >>>> any RAID levels without any additional magic. Dumping to RAID0 and RAID1 >>>> verified to work right now. >>>> >>>> Modified: >>>> projects/graid/head/sys/geom/raid/g_raid.c >>>> projects/graid/head/sys/geom/raid/g_raid.h >>>> projects/graid/head/sys/geom/raid/md_intel.c >>>> >>>> Modified: projects/graid/head/sys/geom/raid/g_raid.c >>>> >>> ============================================================================== >>>> --- projects/graid/head/sys/geom/raid/g_raid.c Tue Jan 25 15:18:10 2011 >>> (r217827) >>>> +++ projects/graid/head/sys/geom/raid/g_raid.c Tue Jan 25 15:34:07 2011 >>> (r217828) >>>> +static int >>>> +g_raid_dump(void *arg, >>>> + void *virtual, vm_offset_t physical, off_t offset, size_t length) >>>> +{ >>>> + struct g_raid_softc *sc; >>>> + struct g_raid_volume *vol; >>>> + struct bio *bp; >>>> + >>>> + vol = (struct g_raid_volume *)arg; >>>> + sc = vol->v_softc; >>>> + G_RAID_DEBUG(3, "Dumping at off %llu len %llu.", >>>> + (long long unsigned)offset, (long long unsigned)length); >>>> + >>>> + bp = g_alloc_bio(); >>>> + bp->bio_cmd = BIO_WRITE; >>>> + bp->bio_done = g_raid_dumpdone; >>>> + bp->bio_attribute = NULL; >>>> + bp->bio_offset = offset; >>>> + bp->bio_length = length; >>>> + bp->bio_data = virtual; >>>> + bp->bio_to = vol->v_provider; >>>> + >>>> + g_raid_start(bp); >>>> + >>>> + while (!(bp->bio_flags& BIO_DONE)) { >>>> + G_RAID_DEBUG(4, "Poll..."); >>>> + g_raid_poll(sc); >>>> + DELAY(10); >>>> + } >>>> + >>>> + G_RAID_DEBUG(3, "Dumping at off %llu len %llu done.", >>>> + (long long unsigned)offset, (long long unsigned)length); >>>> + >>>> + g_destroy_bio(bp); >>>> + return (0); >>>> +} >>> >>> 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? >> >> Actually I've also thought about it. It is trivial to use static >> variable in this particular place. But transformation modules >> (RAID0/RAID1/...) are also allocating some BIOs via g_clone_bio() and >> there it can be more difficult to fix, as several BIOs are allocated >> same time to fulfill original request. > > Hummm. That's a bit unfortunate. It is hardly an excuse, but just for note, ataraid(4) does the same - on-stack allocation for the main request and uma_zalloc() for the children. I will think about possible alternatives. -- Alexander Motin