From owner-freebsd-geom@FreeBSD.ORG Wed Oct 5 21:35:31 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095C6106564A; Wed, 5 Oct 2011 21:35:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA548FC12; Wed, 5 Oct 2011 21:35:29 +0000 (UTC) Received: by wwe3 with SMTP id 3so3083563wwe.31 for ; Wed, 05 Oct 2011 14:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=jnLrks4nO3XwIRezoiRW1kcp/vBMiEUMVYqQhct5ZTM=; b=wsKBJDdNsLUVMyzj4UsUvhlhwTUGHOXeB3aG0gZEp3+rck+ZHGQH0uJ7vhkGWfMxTJ KypSCw3NzYE7KZnughDOTIXzhJB1ONuGzLg7Aydd2eSHkKp7MfVHwl6ySZGOsJjRbjDD hZfjLUdwNZRGQpW90ZC+rwr735f4Fz0RkHV/w= Received: by 10.227.20.67 with SMTP id e3mr3799642wbb.5.1317850529051; Wed, 05 Oct 2011 14:35:29 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (ip212-238-37-54.hotspotsvankpn.com. [212.238.37.54]) by mx.google.com with ESMTPS id y10sm5508942wbm.14.2011.10.05.14.35.26 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 14:35:27 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8CCD69.5000802@FreeBSD.org> Date: Thu, 06 Oct 2011 00:34:33 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C20EA.5060501@FreeBSD.org> <1453791516.20111005132941@serebryakov.spb.ru> In-Reply-To: <1453791516.20111005132941@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events 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: Wed, 05 Oct 2011 21:35:31 -0000 On 05.10.2011 12:29, Lev Serebryakov wrote: > You wrote 5 октября 2011 г., 13:18:34: >> geom_raid addresses this problem in own way. As soon as RAID BIOSes >> expect RAIDs to be built on raw physical devices and probe order is not >> discussed, geom_raid exclusively opens underlying providers immediately >> after detecting supported metadata. So even if volume is broken or > But it could be not first, who taste component of mirror, am I > right? If geom_part will be first, will it "take away" component from > geom_raid? Or it could not? Most of GEOM classes are less aggressive. So geom_raid will any way taste device finally and geom_part should be automatically spoiled as soon as geom_raid open device. > If it works in any case (exclusive open spoils geom_part), it could > be used in all other classes without any metadata infrastructure, That works perfect for case when class (geom_raid) is known to work on raw device. Other RAID classes can be used over partitions, so some care should be taken to avoid false positives. > but > it seems, that geom_mirror, for example, could pickup metadtata from > last parition instead of raw device... > > I'm not sure here. In that case it is helpful to include media size into the metadata. Comparing that value with provider size during taste allows to avoid these false positives. geom_mirror metadata include/check provider size since version 3. Pity that MBR and probably others don't. > But, in any case, maybe standard first 16 bytes of metadata in > pure-GEOM classes and filter in GEOM infrastructure itself ("not pass > provider for tasting to anything but class, written in first 16 bytes > of last sector") looks good idea, IMHO. And what if class is not loaded/supported? There should be a way to manage/clear that label. -- Alexander Motin