Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Sep 2005 08:59:36 +0200
From:      Christian Brueffer <chris@unixpages.org>
To:        Scott Long <scottl@samsco.org>
Cc:        joao.barros@gmail.com, Massimo <massimo@cedoc.mo.it>, freebsd-current@freebsd.org
Subject:   Re: raid framework from OpenBSD
Message-ID:  <20050917065936.GD1151@unixpages.org>
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

--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 16, 2005 at 11:53:34AM -0600, Scott Long 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 framework
> >>>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, 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
>=20
> Give it a try if you're interested.
>=20

FYI, here's a kerneltrap.org article about it.  Looks certainly
interesting.

http://kerneltrap.org/node/5649

- Christian

--=20
Christian Brueffer	chris@unixpages.org	brueffer@FreeBSD.org
GPG Key:	 http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D

--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFDK77YbHYXjKDtmC0RAvvCAJ0Tqes/ouf8Ih9umRzmnXZwrJ7AYQCfYyLU
SVNQ9aVfgLoRa0h0SiQ2UHQ=
=AQrt
-----END PGP SIGNATURE-----

--pY3vCvL1qV+PayAL--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050917065936.GD1151>