From owner-freebsd-geom@FreeBSD.ORG Tue Sep 12 19:22:14 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 4A66B16A407 for ; Tue, 12 Sep 2006 19:22:14 +0000 (UTC) (envelope-from mark@gaiahost.coop) Received: from biodiesel.gaiahost.coop (biodiesel.gaiahost.coop [64.95.78.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A61743D46 for ; Tue, 12 Sep 2006 19:22:13 +0000 (GMT) (envelope-from mark@gaiahost.coop) Received: from gaiahost.coop (host-64-65-195-19.spr.choiceone.net [::ffff:64.65.195.19]) (AUTH: LOGIN mark@hubcapconsulting.com) by biodiesel.gaiahost.coop with esmtp; Tue, 12 Sep 2006 15:21:04 -0400 id 00794085.450708B2.000075F9 Received: by gaiahost.coop (sSMTP sendmail emulation); Tue, 12 Sep 2006 15:17:53 -0400 Date: Tue, 12 Sep 2006 15:17:52 -0400 From: Mark Bucciarelli To: Ulf Lilleengen Message-ID: <20060912191752.GB3164@rabbit> Mail-Followup-To: Ulf Lilleengen , freebsd-geom@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.4.2.1i 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 19:22:14 -0000 On Tue, Sep 12, 2006 at 08:37:33PM +0200, Ulf Lilleengen wrote: > Quoting Mark Bucciarelli : > > > Is anybody using gvinum raid5 in production with 6.1-release? How is > > it > > going? > > > > I run gvinum raid5 in 6.1 Release on a light production server, and I've > not encountered any problems so far, but it _should_ work :) > > 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. Guaranteed to either return non-NULL or produce a KASSERT failure. From the backtrace it look like the latter happened to bug reporter. So not a geom bug. RW's fxr is handy. :) m