Date: Mon, 19 Sep 2005 16:11:27 +0100 From: Joao Barros <joao.barros@gmail.com> To: freebsd-current@freebsd.org Cc: Massimo <massimo@cedoc.mo.it> Subject: Re: raid framework from OpenBSD Message-ID: <70e8236f0509190811227c81a3@mail.gmail.com> In-Reply-To: <432B069E.8000104@samsco.org> References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> <70e8236f050916092979979613@mail.gmail.com> <432B069E.8000104@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/16/05, Scott Long <scottl@samsco.org> wrote: > Joao Barros wrote: > > On 9/14/05, Scott Long <scottl@samsco.org> wrote: > > > >>Massimo wrote: > >> > >>>I would like to know what do you think about new OpenBSD raid framewor= k > >>>management. > >>>http://marc.theaimsgroup.com/?l=3Dopenbsd-misc&m=3D112630095818062 > >>> > >>>Doesn't it seems good stuff which is good for consideration? > >>> > >>>Regards. > >> > >>Creating a unified management tool for multiple RAID architectures has > >>been a Holy Grail for at least 10 years, if not longer. It's > >>deceptively hard, though. While it sounds straight-forward and is > >>relatively easy to do for 1 or 2 architectures, the vast differences in > >>how different architectures work makes it quickly turn into a huge mess= . > >>This is especially true when it comes to topology discovery and > >>management and asynchronous event notification. Often times the only > >>course is to degrade to a very simple, lowest common denominator > >>interface, which then starts to limit the usefulness of the tool. I've > >>been involved in several professional projects in exactly this area, an= d > >>it simply is very, very hard to do well. The OpenBSD work looks > >>interesting, but unless they can demostrate useful operation on more > >>than 1 or 2 architectures, it's not terribly impressive. That's not to > >>say that it can't be done and be a success, but the amount of required > >>effort should not be underestimated. It's relatively easy to come up > >>with a framework and implement one architecture module in it, then tell > >>everyone else to simply add more modules. > >> > >>Also, it's not clear from the email whether the tool has to be manually > >>told to rescan and look for changes in the state of the array (not just > >>SES/SAFTE changes of the component drives). Displaying status on deman= d > >>is fine, but what admin sits in front of their terminal and refreshes > >>their monitoring apps every 5 seconds? The key is to have a an event > >>notification pipeline that can collect events in near real time, filter > >>them in a configurable way, and send out email/pager alerts when > >>appropriate. Also, what does this mean for a datacenter full of > >>machines that need to be monitored? Does a remote terminal session nee= d > >>to be opened on each one in order for monitoring to work? > >> > >>But, even if this particular work degrades into only being a tool for > >>AMI (I assume they mean MegaRAID) controllers, it's still useful and I > >>give them credit for doing it. > > > > > > Having an amr I'm most interested in this, as I guess more people are. > > Given that there is "customer" interest, my question is: is there > > interest from you in this, having it imported to FreeBSD? > > I've looked at the code and I wouldn't mind starting to work on this. > > > > -- > > Joao Barros >=20 > Give it a try if you're interested. >=20 > Scott >=20 I'v talked to marco@openbsd and he seemed very open to the idea and available to assist me :) The machine I have the ami installed is rather slow, a PIII 733MHz and today at work I reserved a Compaq DL380 with a 3.0GHz Xeon and a ciss( I think) which according to the controller's documentation already has bio support, so I'll be able to test both controllers. I have access to Dell (amr mostly), IBM (isp), and Compaq machines so I can try and add support for more controllers :) -- Joao Barros
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70e8236f0509190811227c81a3>