From owner-freebsd-geom@FreeBSD.ORG Sat Jan 14 21:19:03 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC42A16A422 for ; Sat, 14 Jan 2006 21:19:03 +0000 (GMT) (envelope-from brenthostetler@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69F6A43D45 for ; Sat, 14 Jan 2006 21:19:03 +0000 (GMT) (envelope-from brenthostetler@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so864902nzo for ; Sat, 14 Jan 2006 13:19:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nDX5pK+WCtO8N718T/StHPqXIFdXfSQVxqbQ/6D/LjoT3EYUByhT8PcLLMDv/fVb2SncbJeqRRUeSvU550WkbFgqkF+Gjx7CsygnPAUUoeuzNx8nKOHUecCTQSwXDmT/v//7i5lilUSA31FbcfAlVXZYHvQTrxt1DD4snZZWUOM= Received: by 10.36.247.62 with SMTP id u62mr3572373nzh; Sat, 14 Jan 2006 13:19:02 -0800 (PST) Received: by 10.36.90.19 with HTTP; Sat, 14 Jan 2006 13:19:02 -0800 (PST) Message-ID: Date: Sat, 14 Jan 2006 13:19:02 -0800 From: Brent Hostetler To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Metadata info. 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: Sat, 14 Jan 2006 21:19:04 -0000 Hello, I am trying to understand how metadata works properly within the geom framework. I have been having varying problems which I believe are metadata related. I assume from the following quote from gmirro man page that metadata is stored on the last sector of the provider -- ie /dev/ad4, /dev/ad4s1, /dev/stripe1, or /dev/stripe1a -- and not necessarily the last sector of the disk. The gmirror utility uses on-disk metadata (stored in the provider's last sector) to store all needed information. Since the last sector is used for this purpose,it is possible to place a root file system on a mirror. Because of this I notice that when setting up a mirror of a slice you will get error from bsdlabel /dev/ad4 saying bsdlabel: partition c doesn't cover the whole unit!... If you bsdlabel the actual /dev/mirror/data1 it will not issue the warning. The is correct behavior right? So if you are mirroring /dev/ad4 then you would make sure that the last slice that is created is one sector smaller then the media size in sectors such as example 1. Example 1: gmirror label -v -n -b round-robin data1 /dev/ad4 [------ ad4 ------] [-----ad4s1------]* [ad4s1a][-ad4s1d-]* or [----------ad4------------] [-----ad4s1----][--ad4s2-]* [ad4s1a][ad4s1b][-ad4s2a-]* If you are operating on slices then you would make sure the last partition in the mirrored slice would be one sector smaller then the slice size in sectors such as example 2 and 3. Example 2: gmirror label -v -n -b round-robin data1 /dev/ad4s1 [----------- ad4 --------------] [----ad4s1-----]*[---ad4s2-----] [ad4s1d][ad4s1e]*[---ad4s2a----] Example 3: gmirror label -v -n -b round-robin data1 /dev/ad4s1 gmirror label -v -n -b round-robin data2 /dev/ad4s2 [----------- ad4 --------------] [----ad4s1-----]*[---ad4s2----]* [ad4s1d][ad4s1e]*[---ad4s2a---]* If operating on geom's class providers it works the same way correct? Example 4: gmirror label -v -n -b round-robin data1 /dev/stripe/stripe1 [------------stripe1-----------] [------stripe1s1--------------]* [------stripe1s1a-------------]* Thanks.. Brent.