Date: Fri, 22 Sep 2006 09:33:19 -0500 From: Eric Anderson <anderson@centtech.com> To: rick-freebsd@kiwi-computer.com Cc: freebsd-geom@freebsd.org Subject: Re: geom - help ... Message-ID: <4513F42F.1000308@centtech.com> In-Reply-To: <20060922133900.GA31626@megan.kiwi-computer.com> References: <20060921200909.GA13927@megan.kiwi-computer.com> <200609220914.k8M9E1h8077566@lurza.secnetix.de> <20060922133900.GA31626@megan.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rick C. Petty wrote: > On Fri, Sep 22, 2006 at 11:14:01AM +0200, Oliver Fromme wrote: > >> Rick C. Petty wrote: >> > Is everybody forgetting about gvinum? >> >> I _try_ to forget it. :-) >> > > Exactly the type of attitude I predicted. So let's force everybody who > has terabytes in vinum-managed containers to migrate! I mean, who > *doesn't* have a few extra TB of disk space available to aid with that > migration? > While I enjoy the sarcasm as much as anyone, I don't think that's the case. gvinum is being actively worked on, and g* tools are being added, both happening in parallel. I don't think anyone who is a core member or otherwise responsible for gvinum or GEOM has said that it's going away, but I might have missed it. Keep in mind that those who have been bit by gvinum (no matter how long ago) may still have a bad taste in their mouths, and may be nervous to try it again, so they stick with what works. Also, for many people, the g* tools are simpler, if they just want to do a quick simple mirror (for instance). I personally like a full blown volume manager, and gvinum is the closest we have. It needs some work to be really good. To me, gvinum is a different tool for different class of job than the g* tools. They overlap quite a bit, but they still fill different needs. >> Seriously, we've been running vinum with FreeBSD 4.x for >> six years. When upgrading to 6.x (skipping 5.x entirely), >> we changed to gmirror, and my impression is that it is >> much better and easier to manage. I really like it. Once >> > > I wouldn't say it's at all better, although it was easier to setup just a > mirror. Vinum is a volume manager, so I expect it to be more complex than > just setting up a mirror. But I certainly wouldn't call it better. My > mirror rebuilds *every* power outtage (and sometimes even at expected > shutdowns), a behavior I have not witnessed with gvinum. > It's different - and simplicity is worth something to some people. The mirror rebuilding issue is I believe fixed now - Pawel can comment on that better though. Did you submit a bug report for that? > I have yet to see anyone address the inability to change your geom > containers when dealing with live filesystems. Until this is "fixed", > comparing gvinum to other geom classes is apples to oranges. If you > haven't yet been bitten by this problem, then it's no wonder you really > like it. > Agreed, but that may not be a requirement for those who use the g* tools. >> you're familiar with the GEOM concepts, vinum seems to be >> an unnecessarily complex and inflexible beast. >> >> That's just my personal opinion, of course, YMMV. >> > > I am quite familiar with GEOM and I was sad the day vinum was dropped and > gvinum wasn't even close to par with it. It has since improved. I > wouldn't say it's unnecessarily complex or at all inflexible, maybe > you're just not used to managing lots of large volumes? > > I agree that geom is more flexible, and once all the bugs are worked out of > all the layers, maybe someone will write "fvm" to make managing the volumes > easier. I like g/vinum's ability to edit the entire infrastructure from a > single configuration file. Having to repeatedly type a hundred geom > commands sounds like room for human error. > > Your opinion noted and ignored. I'm glad others agree with g/vinum's > importance, or all the poor admins with vinum-managed volumes would be left What I'd like to see personally, is an 'fvm' that uses the same tools or functions as the g* tools, but has the volume management of gvinum, so you can use the fvm to manage the entire view of all volumes, but you could also use gmirror to do the regular gmirror stuff like normal, without breaking things in the fvm. This way, you could take a gmirrored volume, and import it into fvm, and then add a hot spare, etc. I say, if you have an itch, try to scratch it - what I mean is, if it's something you feel passionately about, then either help support it with code, docs, bug reports, etc, or write something better. If you can't code, then start getting the docs and structure written down, and get developers to look at it. If it's well thought out, then you can probably find somebody to help you code it up. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4513F42F.1000308>