From owner-freebsd-hubs@FreeBSD.ORG Mon Oct 24 19:38:16 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 7161F16A41F for ; Mon, 24 Oct 2005 19:38:16 +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 7794E43D4C for ; Mon, 24 Oct 2005 19:38:15 +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 379731933; Mon, 24 Oct 2005 21:38:13 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-10) id 32724-62DC6AD0; Mon, 24 Oct 2005 21:38:12 +0200 Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 0B92B18DA; Mon, 24 Oct 2005 21:38:06 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP; Mon, 24 Oct 2005 21:38:05 +0200 (MET DST) Received: (from j@localhost) by uriah.heep.sax.de (8.13.4/8.13.1/Submit) id j9OJc0Sn032718; Mon, 24 Oct 2005 21:38:00 +0200 (MET DST) (envelope-from j) Date: Mon, 24 Oct 2005 21:38:00 +0200 From: Joerg Wunsch To: freebsd-hubs@freebsd.org Message-ID: <20051024193800.GB31669@uriah.heep.sax.de> References: <59adc1a0510202135s6ee2c00x@mail.gmail.com> <1130098047.975.15.camel@serafim.b61.bg.wi> <59adc1a0510231325u25bef8e8v@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59adc1a0510231325u25bef8e8v@mail.gmail.com> 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.108; host: uriah.heep.sax.de) Cc: 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: Mon, 24 Oct 2005 19:38:16 -0000 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.) 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.'' -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)