From owner-freebsd-current@FreeBSD.ORG Wed Oct 5 22:12:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC96A1065674; Wed, 5 Oct 2011 22:12:54 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8975C8FC0C; Wed, 5 Oct 2011 22:12:54 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A64732842B; Thu, 6 Oct 2011 00:12:52 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C5D432842A; Thu, 6 Oct 2011 00:12:51 +0200 (CEST) Message-ID: <4E8CD662.90202@quip.cz> Date: Thu, 06 Oct 2011 00:12:50 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Scot Hetzel References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 22:12:54 -0000 Scot Hetzel wrote: > 2011/10/5 Miroslav Lachman<000.fbsd@quip.cz>: >> I am waiting years for the moment, when these GEOM problems will be fixed, >> so I am really glad to see your interest! >> It will be move to right direction even if changes will not be backward >> compatible. >> The current state is too fragile to be used in production. Gmirror alone can >> be used, glabel alone can be used, GPT alone can be used... but mix it all >> stacked together is way to hell. >> >> e.g. Using GPT on glabeled provider always ends with error message about >> corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I >> cannot use glable on devices and iSCSI device can have different number on >> each reboot? I wrote about it almost 2 years ago) >> > You don't need to use glabel on GPT disks, as gpart has it's own way > to label GPT disks: [...] The point was that glabel on disk device is successful, gpartitioning on glabeled device is successful, but metadata handling / device tasting is wrong after reboot and this should be fixed, not worked around. Otherwise thank you for example with GPT labels, it can be useful in some cases. Miroslav Lachman