Date: Tue, 17 Mar 2009 19:21:19 +0000 From: Ulf Lilleengen <ulf.lilleengen@gmail.com> To: Nenhum_de_Nos <matheus@eternamente.info> Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] Merge of projects/gvinum to head Message-ID: <20090317192119.GA18089@carrot> In-Reply-To: <9a42260f71d0d310ee449a86a0c87f88.squirrel@cygnus.homeunix.com> References: <20090316155800.GA2257@carrot> <20090316155957.GA2385@carrot> <b899df246a4ea808b9f048c635a11fc4.squirrel@10.1.1.10> <20090317094911.GA2155@carrot.tudelft.net> <796884d5ade2c19ab4f46318e2147128.squirrel@cygnus.homeunix.com> <20090317143952.GA1630@carrot> <9a42260f71d0d310ee449a86a0c87f88.squirrel@cygnus.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On tir, mar 17, 2009 at 12:09:08pm -0300, Nenhum_de_Nos wrote: > > On Tue, March 17, 2009 11:39, Ulf Lilleengen wrote: > > On tir, mar 17, 2009 at 09:52:31am -0300, Nenhum_de_Nos wrote: > >> > >> On Tue, March 17, 2009 06:49, Ulf Lilleengen wrote: > >> > On man, mar 16, 2009 at 11:07:12pm -0300, Nenhum_de_Nos wrote: > >> >> > >> >> On Mon, March 16, 2009 12:59, Ulf Lilleengen wrote: > >> >> > On man, mar 16, 2009 at 04:58:00pm +0100, Ulf Lilleengen wrote: > >> >> >> Hello, > >> >> >> > >> >> >> This is a heads-up for a merge of gvinum project code into HEAD. > >> This > >> >> >> means > >> >> >> that gvinum implementation will be changed some. The code is based > >> on > >> >> >> the > >> >> >> work done by Lukas Ertl as well as the work I did before/during > >> >> Google > >> >> >> SoC > >> >> >> 2007 and afterwards. It has been staying in p4 for some time, and > >> >> then > >> >> >> moved > >> >> >> to the subversion project repository not long ago. The main reason > >> >> for > >> >> >> the > >> >> >> delay of getting this into HEAD have been the lack of reviewers of > >> >> the > >> >> >> code, > >> >> >> but after some discussion and help from testers, I've decided this > >> is > >> >> a > >> >> >> good > >> >> >> time to get it in (should perhaps have been merged a bit earlier) > >> >> >> Testers > >> >> >> have spotted several differences from the original gvinum, and > >> I've > >> >> >> tried to > >> >> >> make it behave as the old implementation wherever that seemed the > >> >> best > >> >> >> way to > >> >> >> go. Luckily, the work has gotten a bit of attention lately, thanks > >> to > >> >> >> Rick C. > >> >> >> Petty for helping out with testing and bugfixing, as well as all > >> >> others > >> >> >> who > >> >> >> have dared to run the new gvinum. So, what does this update offer? > >> >> > > >> >> > And I plan on importing it within 1-2 weeks :) > >> >> > >> >> great work, thanks. > >> >> > >> >> what's the status of raid5 ? is it ok to production enviroments ? I > >> have > >> >> been using gmirror and gstripe just cause I can't do raid5 and I'm > >> >> waiting > >> >> for ZFS to hit production state. > >> >> > >> > I would say that since the raid5 code hasn't changed much in terms of > >> > functionality, meaning that much of the code concerning raid5 is the > >> same, > >> > it > >> > should provide at least the same production quality as gvinum in 7.x. > >> What > >> > are your experiences with gvinum raid5 in 7.x? > >> > >> none, as I always read that the code was not ok or was not doing what > >> raid5 is all about (those parity counts), I never was brave enough to > >> try > >> it. is this all wrong ? > >> > > I've not heard of any issues with the actual raid5 algorithms to be wrong, > > no, no, not wrong, but not implemented. > Oh, it's been implemented since FreeBSD 5.0 :) (the verst version of geom vinum). > so, if I use raid5 now (must see docs to know how to) it will do its job > right if I replace one disk ? (as if one would die) Yes, but the thing is that you might get problems if you don't do everything strictly by the book. For instance, if the disk fails, and you have to reboot to replace it, the volume will go up having the whole volume in the wrong state, and you must do setstate commands appropriately to set the volume as degraded before you insert the disk again. If you can just hot-swap the disk, it should be quite easy without problems just using the move command. This is a case where the new gvinum should be much less scary to use, so I wouldn't recommend using the old version unless you have hot-swap disks and/or previous experience with gvinum. -- Ulf Lilleengen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090317192119.GA18089>