Date: Mon, 24 Oct 2005 21:38:00 +0200 From: Joerg Wunsch <j@uriah.heep.sax.de> To: freebsd-hubs@freebsd.org Subject: Re: extending volumes Message-ID: <20051024193800.GB31669@uriah.heep.sax.de> In-Reply-To: <59adc1a0510231325u25bef8e8v@mail.gmail.com> References: <59adc1a0510202135s6ee2c00x@mail.gmail.com> <1130098047.975.15.camel@serafim.b61.bg.wi> <59adc1a0510231325u25bef8e8v@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051024193800.GB31669>