From owner-freebsd-current@FreeBSD.ORG  Thu Oct  6 13:56:23 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0A18D106566C;
	Thu,  6 Oct 2011 13:56:23 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru
	[IPv6:2a01:4f8:131:60a2::2])
	by mx1.freebsd.org (Postfix) with ESMTP id B5BFD8FC12;
	Thu,  6 Oct 2011 13:56:22 +0000 (UTC)
Received: from lion.home.serebryakov.spb.ru (unknown
	[IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6])
	(Authenticated sender: lev@serebryakov.spb.ru)
	by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6C1944AC2D; 
	Thu,  6 Oct 2011 17:56:21 +0400 (MSD)
Date: Thu, 6 Oct 2011 17:56:11 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Organization: FreeBSD
X-Priority: 3 (Normal)
Message-ID: <711721489.20111006175611@serebryakov.spb.ru>
To: Miroslav Lachman <000.fbsd@quip.cz>
In-Reply-To: <4E8DA627.60003@quip.cz>
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>
	<CACdU+f8mA1wLUnHVyrJwaf89ahf2oc_904=8mme7kkBLxLSCCQ@mail.gmail.com>
	<4E8CD662.90202@quip.cz> <j6k252$hpm$1@dough.gmane.org>
	<4E8DA627.60003@quip.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: freebsd-current@freebsd.org, Ivan Voras <ivoras@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
Reply-To: lev@FreeBSD.org
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2011 13:56:23 -0000

Hello, Miroslav.
You wrote 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16:59:=
19:

> I am not a GEOM expert, but isn't it wrong concept, that glabel writes
> its metadata and publish original device size? If some GEOM write=20
> metadata at last sector (or first), then it should shrink the published
> size (or offset). Or is the problem at geom_part, that it is writing=20
> metadata past the advertised end of the device?
  Good point.

> e.g. If I have disk device with size of 100 sectors and glabel metadata
> is stored at the last sector, then glabel should shrink the advertised
> size to 99 sectors - then GPT secondary table will be at sector 99=20
> instead of 100.

> The current state is simply wrong, because user can do something what
> cannot work and is not documented anywhere.
  It is Ok in UNIX way, in general. You should be able to shoot your
 leg, it is good :)

  But if geom_label doesn't reduce its provider to count its own
 metadata, it looks like a bug!

--=20
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>