Date: Tue, 25 Oct 2005 10:25:07 +0300 From: George Danchev <danchev@spnet.net> To: freebsd-hubs@freebsd.org Subject: Re: extending volumes Message-ID: <200510251025.08236.danchev@spnet.net> In-Reply-To: <20051024193800.GB31669@uriah.heep.sax.de> References: <59adc1a0510202135s6ee2c00x@mail.gmail.com> <59adc1a0510231325u25bef8e8v@mail.gmail.com> <20051024193800.GB31669@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510251025.08236.danchev>