From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 13:56:23 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 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 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> <4E8CD662.90202@quip.cz> <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 , freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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