From owner-freebsd-geom@FreeBSD.ORG Tue Jan 9 19:16:46 2007 Return-Path: X-Original-To: geom@freebsd.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6631D16A407 for ; Tue, 9 Jan 2007 19:16:46 +0000 (UTC) (envelope-from fernan.aguero@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 26F9413C441 for ; Tue, 9 Jan 2007 19:16:44 +0000 (UTC) (envelope-from fernan.aguero@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so3971270nzh for ; Tue, 09 Jan 2007 11:16:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SeO/TmGD1e10kjVh+VCBXXeATxwW9HWoukqslbeClVyu7AyDQ2M8Uo2EUKsHc8ZIGEn7NpDWNqAZ/okfVtGkj/Ier4cIJODNPOjsOwXatnoOvrOiD4bejpS5crc6HqN7TP/lyARhbrIA8d1//Cz/WMyvxhiAgvmJuc89GJDEtYQ= Received: by 10.35.121.9 with SMTP id y9mr51242770pym.1168370203424; Tue, 09 Jan 2007 11:16:43 -0800 (PST) Received: by 10.35.16.1 with HTTP; Tue, 9 Jan 2007 11:16:43 -0800 (PST) Message-ID: <520894aa0701091116t424ca75coc2167eacea8f1a38@mail.gmail.com> Date: Tue, 9 Jan 2007 16:16:43 -0300 From: "Fernan Aguero" To: "Pawel Jakub Dawidek" In-Reply-To: <20070109140625.GD62430@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <520894aa0701081445i43d76098m418ce695d2133e53@mail.gmail.com> <20070109001437.GC97624@in-addr.com> <520894aa0701081813x3925b7f1r278785bb01f4232@mail.gmail.com> <20070109083846.GA62430@garage.freebsd.pl> <520894aa0701090524t217a36ecje1cf7b40d8a2a7e0@mail.gmail.com> <20070109140625.GD62430@garage.freebsd.pl> Cc: geom@freebsd.org Subject: Re: clear metadata using dd? 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: Tue, 09 Jan 2007 19:16:46 -0000 On 1/9/07, Pawel Jakub Dawidek wrote: > On Tue, Jan 09, 2007 at 10:24:04AM -0300, Fernan Aguero wrote: > > On 1/9/07, Pawel Jakub Dawidek wrote: > > >On Mon, Jan 08, 2007 at 11:13:15PM -0300, Fernan Aguero wrote: > > >> On 1/8/07, Gary Palmer wrote: > > >> >On Mon, Jan 08, 2007 at 07:45:06PM -0300, Fernan Aguero wrote: > > >> > > >> [snipped] > > >> > > >> >> gama# gstripe label -v gs0 /dev/ad4s3 /dev/ad6s3 > > >> >> Can't store metadata on /dev/ad4s3: Operation not permitted. > > >> >> > > >> >> This might be because ad4s3 had been part of a gmirror device before I > > >> >> reorganized my disks and moved the mirror to the s2 slice. > > >> > > >> [snipped] > > >> > > >> >Any reason that "gstripe clear" or "gmirror clear" doesn't work? Thats what > > >> >they're meant to do, as far as I know. > > >> > > >> because ad4s3 is no longer part of gm0? > > > > > >You get "Operation not permitted." because someone already keep ad4s3 > > >open for writing. Could you send output of 'sysctl -b kern.geom.confxml' > > >so we can find out who? > > > > http://omega.iib.unsam.edu.ar/kern.geom.confxml > [...] > > In this output size of ad4 is 160041885696 bytes. > > In your first post, slices are configured this way: > > gama# fdisk -s /dev/ad4 > /dev/ad4: 310101 cyl 16 hd 63 sec > Part Start Size Type Flags > 1: 63 16771041 0xa5 0x00 > 2: 16771923 146795229 0xa5 0x80 > 3: 146795292 188742708 0xa5 0x00 > > If ad4s3 starts at 146795292 sectors and is 188742708 sectors big, which > bascially means, that ad4s3 end at offset: > > (146795292+188742708)*512 = 171795456000 bytes > > 160041885696 < 171795456000, which means your slices are misconfigured. > Correct that and it should work. OK, so perhaps the problem is that I used 160Gb in my calculations for the media size, expecting that fdisk will 'round down' the size of the last slice to match available space. I recalculated all the start/length values for my slices and changed the fdisk.config I used with fdisk -f and now everything is fine. Thanks! but why was I ever allowed to go farther from the end of the media size? why didn't fdisk say anything? why didn't geom -- now I know that every single storage provider is managed by geom :) -- say anything? Wouldn't it be good if one could tell fdisk to create a slice to start at a given sector and use '*' as the length (much as bsdlabel allows) so that the slice would occupy all remaining space?, like in p 3 165 146800795 * Again, thanks! fernan -- Fernan Aguero