From owner-freebsd-geom@FreeBSD.ORG Thu Jun 23 23:04:05 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 CBF901065674; Thu, 23 Jun 2011 23:04:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 200CF8FC0C; Thu, 23 Jun 2011 23:04:04 +0000 (UTC) Received: by fxm11 with SMTP id 11so2361863fxm.13 for ; Thu, 23 Jun 2011 16:04:04 -0700 (PDT) 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=PPo4I5IN1YF9/ATurxJFFwVDgRLLlVYm21MHc0fOqQ8=; b=hEfVi756nhxj+V3sVRGRZoZurEaSYZqSgr4UXjX91GXivX2phvVps0dGhYAz9bFGJw LDl8oZ6HKARLLTBco8SR7Vcek7Uo5D7N0nwqXMSl0JJo3FsI8TimzYLlsPgD/Xph7Wad 8QWsTi1cj5/hVN7uHeYphNLK+TWyJGJvGOw+k= 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=U8PfKBiJg+pDEJnI7d5YEMm1wBFQmNj5iPeminOXcu/Bz2oBjAQllTOGiy01qyTCZn gWFHo7utRKHEUn2Cl5KMl5vNQ1/ksdOPRXVRVXJo7ex6CJborHMGWyypkRCjLj9KGybE vx2fiIOBTXRtwXq+r9Za8rBLr9gZ8fIpaBicQ= Received: by 10.223.1.70 with SMTP id 6mr3436019fae.82.1308870244028; Thu, 23 Jun 2011 16:04:04 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e16sm1278371fak.17.2011.06.23.16.04.02 (version=SSLv3 cipher=OTHER); Thu, 23 Jun 2011 16:04:03 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E03C621.4050505@FreeBSD.org> Date: Fri, 24 Jun 2011 02:02:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Gavin Atkinson References: <1308851620.3853.34.camel@buffy.york.ac.uk> <4E038051.3020809@FreeBSD.org> <4e03c408.45822a0a.66cf.ffffe135SMTPIN_ADDED@mx.google.com> In-Reply-To: <4e03c408.45822a0a.66cf.ffffe135SMTPIN_ADDED@mx.google.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:04:06 -0000 Gavin Atkinson wrote: > 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. It may depend on metadata format. For example, Intel format depends on valid provider serial number. It can't be used on providers without serial number -- it won't be able to find place in array for the components. Not sure if any non-hardware provider has serial number, so this limitation can be effectively the same. >>> 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? May be not. Just haven't tried. Should be only few lines. -- Alexander Motin