From owner-freebsd-hubs@FreeBSD.ORG Tue Oct 25 07:25:14 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 5527116A41F for ; Tue, 25 Oct 2005 07:25:14 +0000 (GMT) (envelope-from danchev@spnet.net) Received: from mail.data.bg (mail.data.bg [195.149.248.177]) by mx1.FreeBSD.org (Postfix) with SMTP id 6399343D45 for ; Tue, 25 Oct 2005 07:25:12 +0000 (GMT) (envelope-from danchev@spnet.net) Received: (qmail 24826 invoked by uid 104); 25 Oct 2005 07:25:10 -0000 Received: from danchev@spnet.net by mail by uid 104 with qmail-scanner-1.16 (spamassassin: 2.20. uvscan: v4.1.40/v4100. Clear:SA:0(-1.2/8.0):AWL, BAYES_50 autolearn=ham version=3.0.3. Processed in 2.046644 secs); 25 Oct 2005 07:25:10 -0000 X-Spam-Tag-Score: SA:0(-1.2/8.0):AWL,BAYES_50 autolearn=ham version=3.0.3 X-Spamassassin-Hits: -1.2 X-Spamassassin-Tests: AWL,BAYES_50 autolearn=ham version=3.0.3 Received: from unknown (HELO danchev5.ddns.homelan.bg) (83.97.29.139) by smtp.data.bg with SMTP; 25 Oct 2005 07:25:08 -0000 From: George Danchev To: freebsd-hubs@freebsd.org Date: Tue, 25 Oct 2005 10:25:07 +0300 User-Agent: KMail/1.7.2 References: <59adc1a0510202135s6ee2c00x@mail.gmail.com> <59adc1a0510231325u25bef8e8v@mail.gmail.com> <20051024193800.GB31669@uriah.heep.sax.de> In-Reply-To: <20051024193800.GB31669@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251025.08236.danchev@spnet.net> Subject: Re: extending volumes X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD Distributions Hubs: mail sup ftp" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 07:25:14 -0000 On Monday 24 October 2005 22:38, Joerg Wunsch wrote: > As Dimitar Vasilev wrote: > > > I think you're attempting to do impossible. > > > > > > Under Solaris and AIX it is perfectly possible - however they're > > > another beer. > > Nope. Extending a striped volume by another stripe is impossible in > about any system I've seen so far. (Extending a striped volume by > concatenating another set of stripes is something different, and I > guess GEOM's architecture would allow for that.) Thanks for the nice summary. It was really informative ! > Extending file systems is something different. AIX can do it, yes, > and can even shrink them (which is much more work), albeit it might > take forever, depending on the load. Solaris' growfs isn't that much > more capable than FreeBSD's growfs is, except Solaris has got the > lockfs(2) syscall so they can grow a filesystem online, while FreeBSD > requires the filesystem to be unmounted. Solaris with vxfs is about > the same as AIX is (but you gotta pay a lot of bucks for that). > > I think vinum could be tricked into extending a stripe set by another > stripe set (so a concetanation will result), but I'm not sure about > it, and would generally be very careful with that. (Not sure about > gvinum here, perhaps it can do it as well.) But that doesn't seem to > be Dimitar's intention. See above, inserting another stripe row will > completely change the topology, so the file system on top of the > volume will become invalid. > > (I've seen a feature like that being announced in some hardware RAID > array quite some time ago, but when we tried, it took forever due to > the massive amount of copy operations needed, and then it crashed > anyway.) > > ISTR someone once analyzed that striping doesn't make much sense with > modern UFSes at all, as the UFS itself distributes the data already > well enough, so a concatenation yields the same overall performance. > Concetanetions are way easier to handle in any respect, and see above, > once you've added something to the concat, you could use growfs to > tell the file system to pick up the volume's new size. I've done this > a number of times with FreeBSD (albeit with [g]vinum-based volumes), > but I've also seen it fail occasionally. :-/ But then, I've also > seen Solaris' growfs getting stuck, and trashing a volume, as well > as vxvm trashing several hundred Megabytes of data. To quote a > signature my colleague is using: ``Failure is not an option. It comes > bundled with the software.'' Let me turn the question this way. Curently we have done the stripe as follows: dd if=/dev/zero of=/dev/ad2 bs=512 count=79 dd if=/dev/zero of=/dev/ad3 bs=512 count=79 gstripe load gstripe label -v -s 65536 data /dev/ad2 /dev/ad3 newfs -U /dev/stripe/data mount /dev/stripe/data /mnt/storage Everything works as expected. Then we run almost out of space of that /dev/stripe/data and we have 2 x 250 GB diska we want to add to this stripe. 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 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 ? If there is another way to add the spare disks to the existing stripe preserving the data there I'm all eager to hear about it. I'm not sure how to approach the gvinum in our case. I tried to look at the sources ( kernel: src/sys/geom/label/*; userland: serc/sbin/geom/class/label/*) but can't manage to find my way aroud ;-) Can you please be more specific about the exact commands we should issue/read about/consider. Thank you very much for your time. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB