From owner-freebsd-geom@FreeBSD.ORG Tue Sep 12 18:44:56 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 099A916A403 for ; Tue, 12 Sep 2006 18:44:56 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [209.191.69.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 8469D43D45 for ; Tue, 12 Sep 2006 18:44:55 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 33679 invoked by uid 60001); 12 Sep 2006 18:44:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=34ntHe+SfPutpw+pkWNf2C5NBbgH3plqb3o4e/VKn3hrUjdhsKSGGFU2dhp6XdmftFc/07Bff19SI1dpwIczwk+RG27QMnYd0ukr35ll+5UcY9mMkRGbaCdzO1f7MFkc/JHdi1WBFcDLVUTZkhiB0b2oIUztPlTAEMUGXujqpEM= ; Message-ID: <20060912184453.33677.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.69.36] by web30313.mail.mud.yahoo.com via HTTP; Tue, 12 Sep 2006 11:44:53 PDT Date: Tue, 12 Sep 2006 11:44:53 -0700 (PDT) From: "R. B. Riddick" To: Ulf Lilleengen , Mark Bucciarelli In-Reply-To: <1158086253.4506fe6d6d6fe@webmail.ntnu.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@freebsd.org Subject: Re: gvinum raid5 in production X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 18:44:56 -0000 --- Ulf Lilleengen wrote: > Quoting Mark Bucciarelli : > > Is anybody using gvinum raid5 in production with 6.1-release? How is > > it going? > > About the PR's you found I'm not sure of what's a gvinum bug or not of > them, but at the thing about not checking NULL pointers for g_malloc is > because when passing the M_WAITOK flag to g_malloc (or kernel malloc > for instance), it is guaranteed to not return NULL because the flag > tells malloc to wait for resources to be freed. > As far as I understood GEOM it does not like to sleep in g_up or g_down threads... So we cannot use M_WAITOK in gv_down()... I personally do it in my geom_raid5 class (downloadable tar-ball: http://home.tiscali.de/cmdr_faako/geom_raid5.tbz and .../geom_cache.tbz) different: I just put the pointer to the bio into a worker queue (that does not need any malloc's; just bending some pointer attributes) and then in the worker thread I process those requests... Maybe we should create a queue for that purpose for gvinum, too? -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com