From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 07:00:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EEC16A41F for ; Sat, 17 Sep 2005 07:00:10 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F7F43D46 for ; Sat, 17 Sep 2005 07:00:09 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IMY007PF8S7MJ@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Sat, 17 Sep 2005 09:00:08 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 17 Sep 2005 09:00:07 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j8H707Zj029685; Sat, 17 Sep 2005 09:00:07 +0200 (MEST) Received: from moria.hitnet.rwth-aachen.de ([137.226.181.149] helo=haakonia.hitnet.rwth-aachen.de) by bigboss.hitnet.rwth-aachen.de with esmtp (Exim 3.35 #1 (Debian)) id 1EGWgB-0000Sf-00; Sat, 17 Sep 2005 09:00:07 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id F3E132843F; Sat, 17 Sep 2005 08:59:36 +0200 (CEST) Date: Sat, 17 Sep 2005 08:59:36 +0200 From: Christian Brueffer In-reply-to: <432B069E.8000104@samsco.org> To: Scott Long Message-id: <20050917065936.GD1151@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=pY3vCvL1qV+PayAL; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.9i X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> <70e8236f050916092979979613@mail.gmail.com> <432B069E.8000104@samsco.org> Cc: joao.barros@gmail.com, Massimo , freebsd-current@freebsd.org Subject: Re: raid framework from OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 07:00:10 -0000 --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 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--