From owner-freebsd-geom@FreeBSD.ORG Thu Sep 14 16:28:22 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 9A00E16A59B for ; Thu, 14 Sep 2006 16:28:22 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30306.mail.mud.yahoo.com (web30306.mail.mud.yahoo.com [209.191.69.68]) by mx1.FreeBSD.org (Postfix) with SMTP id B555043D78 for ; Thu, 14 Sep 2006 16:28:18 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 74001 invoked by uid 60001); 14 Sep 2006 16:28:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q0JoJz5GUkr7P66cpRbSNcJhfuzBuQ9Q0iNylrJGgDqfmYRHcshI24LDXv3csGnxw5PNPEtlCdK2hbE/II5SyyUvI6bSVf056rIvpTeO+xHP0aPJJ25EciIqqtb8S6Pa/a5L+bfRMbGjEBMQ3aYNoISEbOZDK8UiPll66hn+iq8= ; Message-ID: <20060914162817.73998.qmail@web30306.mail.mud.yahoo.com> Received: from [213.54.79.187] by web30306.mail.mud.yahoo.com via HTTP; Thu, 14 Sep 2006 09:28:17 PDT Date: Thu, 14 Sep 2006 09:28:17 -0700 (PDT) From: "R. B. Riddick" To: freebsd-geom@FreeBSD.ORG In-Reply-To: <200609141559.k8EFxp2P056652@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: gmirror size question 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: Thu, 14 Sep 2006 16:28:22 -0000 Hi! --- Oliver Fromme wrote: > If the new disk is sligtly larger, I guess there shouldn't > be a problem. When adding the new drive, gmirror will > simply ignore the excess blocks, right? > Yup! > However, I guess I'll run into trouble if the new drive > is slightly smaller. Therefore, it came to my mind that > it might make sense to make the mirror slightly smaller > from the beginning, i.e. let gmirror use only the first > 73GB of the 74GB available. That should be enough of a > safety margin. > g_mirror.c says in g_mirror_check_metadata(): if (sc->sc_mediasize > pp->mediasize) { G_MIRROR_DEBUG(1, "Invalid size of disk %s (device %s), skipping.", pp->name, sc->sc_name); return (EINVAL); } > However, how do I do that? gmirror(8) doesn't provide > an option to specify the size of the consumer, or to > let it ignore a certain amount of space at the end of > it. > It is important to care about that before IT happens... :-) Because: The file system might expect the last few sectors to exist... I would use gnop during the "gmirror label" command in the hope, that gmirror stores the mediasize permanently without further future checking... But that is just a quick shot... > My next thought was to create separate slice tables on > both disks, with one slices of 73GB each (letting 1GB > stay unused), and then put gmirror onto the slices > (da0s1 + da1s1) instead of the whole disks (da0 + da1). > I guess that would work, but in that case the MBR and > slice tables wouldn't be mirrored, which could lead to > trouble if one drive fails and GEOM (or anything else) > tried to access the MBR for whatever reason. > Gah! :-) -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com