From owner-freebsd-hubs@FreeBSD.ORG Wed Oct 26 21:40:45 2005 Return-Path: X-Original-To: freebsd-hubs@freebsd.org Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFBED16A420 for ; Wed, 26 Oct 2005 21:40:44 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEF4543D46 for ; Wed, 26 Oct 2005 21:40:43 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from localhost (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id DB77718DA; Wed, 26 Oct 2005 23:40:41 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-10) id 44752-36C5D59C; Wed, 26 Oct 2005 23:40:41 +0200 Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 71E51242; Wed, 26 Oct 2005 23:40:35 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP; Wed, 26 Oct 2005 23:40:35 +0200 (MET DST) Received: (from j@localhost) by uriah.heep.sax.de (8.13.4/8.13.1/Submit) id j9QLeYVX044751; Wed, 26 Oct 2005 23:40:34 +0200 (MET DST) (envelope-from j) Date: Wed, 26 Oct 2005 23:40:34 +0200 From: Joerg Wunsch To: George Danchev Message-ID: <20051026214034.GB42397@uriah.heep.sax.de> References: <59adc1a0510202135s6ee2c00x@mail.gmail.com> <59adc1a0510231325u25bef8e8v@mail.gmail.com> <20051024193800.GB31669@uriah.heep.sax.de> <200510251025.08236.danchev@spnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510251025.08236.danchev@spnet.net> User-Agent: Mutt/1.4.2.1i X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on uriah.heep.sax.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.5 tests=none autolearn=failed version=3.0.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-10; AVE: 6.32.0.8; VDF: 6.32.0.114; host: uriah.heep.sax.de) Cc: freebsd-hubs@freebsd.org Subject: Re: extending volumes X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: "FreeBSD Distributions Hubs: mail sup ftp" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 21:40:45 -0000 As George Danchev wrote: > Let me turn the question this way. Curently we have done the stripe as > follows: > gstripe label -v -s 65536 data /dev/ad2 /dev/ad3 > ... As far as I understand it we should umount the device and concat da4 > and da6 to the existing da2 and da3 ones. > > gconcat label -v data /dev/da2 /dev/da3 /dev/da4 /dev/da6 > growfs /dev/stripe/data No, that won't work. It will create a concetanation of all four devices. My suggestion is that you can omit the striping completely (as it doesn't yield a significant performance gain), and instead initially set up a concat of da2 and da3. Then, when you run out of space, just concat more devices to it. This will grow the volume. You still need to grow the filesystem afterwards. Supposedly, GEOM is fully stackable, so you could also initially setup a stripe set, and if you run out of space, setup another stripe set, and concatenate both to a large volume. > The real question is: can we preserve the data already existing > there or the new label command will trash the metadata already being > on the disks last sectors ? data != metadata I think for my initial suggestion, no problems will arise, as simply each device has its own set of metadata, and the real data aren't affected by metadata changes. However, if you've initially got a stripe, and later want to change that into two stripes that are concatenated, you cannot use the "automatic" (i.e. "label" method), as I understand the documentation, as the new concat's label would trash the last (non-metadata) sector of the already existing stripe set. You have to use manual configuration then. Of course, if you use manual configuration for everything, you're always on the safe side, as no metadata will be written to disk. > Can you please be more specific about the exact commands we should > issue/read about/consider. Sorry, I haven't used GEOM for this kind of operations so far, so I can only guess based on the documentation (which is pretty clear though). I'm more used to full volume management (where you typically don't hand out all the available storage initially but rather keep all unused space available in the volume manager for later assignment), and all my experience comes from vinum and now gvinum (and other volume managers, like Veritas and Solaris VM). vinum (and Veritas VM) follows a completely different approach for metadata, as each physical disc added to volume management (which can be a slice and/or partition) stores its own copy of the metadata right at the beginning (which is a full redundant copy, i.e. each disc has the same full set of metadata). The remainder of the disc is then available for data assignment, and no metadata will ever be written there. That way, growing concatenated volumes is always without risk. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)