From owner-freebsd-geom@FreeBSD.ORG Thu Jun 23 23:11:48 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E598106566C for ; Thu, 23 Jun 2011 23:11:48 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from gse-mta-27.emailfiltering.com (gse-mta-27-tx.emailfiltering.com [194.116.198.158]) by mx1.freebsd.org (Postfix) with ESMTP id 808028FC08 for ; Thu, 23 Jun 2011 23:11:47 +0000 (UTC) Received: from mail-gw5.york.ac.uk ([144.32.129.29]) by gse-mta-27.emailfiltering.com with emfmta (version 4.8.2.32) by TLS id 1045647620 for mav@FreeBSD.org;172ed6f60f60bd64; Thu, 23 Jun 2011 23:53:46 +0100 Received: from ury.york.ac.uk ([144.32.108.81]:35733) by mail-gw5.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QZsmP-0006hx-Uq; Thu, 23 Jun 2011 23:53:45 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1QZsmP-0007j3-Mo; Thu, 23 Jun 2011 23:53:45 +0100 Date: Thu, 23 Jun 2011 23:53:45 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@"ury.york.ac.uk." To: Alexander Motin In-Reply-To: <4E038051.3020809@FreeBSD.org> Message-ID: References: <1308851620.3853.34.camel@buffy.york.ac.uk> <4E038051.3020809@FreeBSD.org> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: freebsd-geom@FreeBSD.org Subject: Re: geom_raid tasting providers that can't be raw disks 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: Thu, 23 Jun 2011 23:11:48 -0000 On Thu, 23 Jun 2011, Alexander Motin wrote: > On 23.06.2011 20:53, Gavin Atkinson wrote: > > While debugging a problem that looks like it was unrelated to geom_raid, > > I realised that it tastes all providers, including each partition and > > slice on raid devices it itself created. > > > > Given that geom_raid is purely a replacement for ataraid, the only place > > that the metadata can be valid is on the raw disk itself. > > In general case nothing prevents from using graid on partitions (instead of > gmirror/gstripe/...) if BIOS support is not needed. I think this check at > least should be moved to specific metadata modules in case if we later add > support for abstract gxxx metadata formats. OK, thanks. I had believed that this was purely for use on hardware. If the intention is that this module can be used on arbitrary providers, then I see no reason to change things. > > Also, should geom_raid be in GENERIC? ataraid was, and it's one less > > "gotcha" for upgrades. Given the lack of ar0 -> raid/r0 aliases, the > > upgrade is painful enough for users already, putting it in GENERIC may > > at least help slightly... > > Aggressive tasting for each metadata format was actually the reason why I > haven't added it. If we load all GEOM modules, then some floppy tasting will > take ages. OK, that makes sense. I had a bit of a look this evening as to the best way to try to get code in place to provide /dev/arX compatibility nodes whenever a geom_raid array is discovered. Is there any reason that I shouldn't take exactly the same approach as you have done with the adX -> adaX compatibility shims? Thanks, Gavin