Re: raid framework from OpenBSD

On Mon, 19 Sep 2005 16:11:27 +0100
Joao Barros <joao.barros_at_gmail.com> wrote:

> On 9/16/05, Scott Long <scottl_at_samsco.org> wrote:
> > Joao Barros wrote:
> > > On 9/14/05, Scott Long <scottl_at_samsco.org> wrote:
> > >
> > >>Massimo wrote:
> > >>
> > >>>I would like to know what do you think about new OpenBSD raid framework
> > >>>management.
> > >>>http://marc.theaimsgroup.com/?l=openbsd-misc&m=112630095818062
> > >>>
> > >>>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, and
> > >>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 demand
> > >>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 need
> > >>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
> > 
> > Give it a try if you're interested.
> > 
> > Scott
> > 
> 
> I'v talked to marco_at_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 :)
> 
Great, keep us informed. I have a couple of AMI controllers myself and will be happy to help out with testing.

Cheers,
Marcin