From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 16:03:15 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 CF0AE16A41F for ; Mon, 19 Sep 2005 16:03:15 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF76D43D48 for ; Mon, 19 Sep 2005 16:03:14 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 2F6083982A; Mon, 19 Sep 2005 18:03:09 +0200 (CEST) Date: Mon, 19 Sep 2005 16:02:54 +0000 From: Marcin Jessa To: joao.barros@gmail.com Message-Id: <20050919160254.38fb974a.lists@yazzy.org> In-Reply-To: <70e8236f0509190811227c81a3@mail.gmail.com> References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> <70e8236f050916092979979613@mail.gmail.com> <432B069E.8000104@samsco.org> <70e8236f0509190811227c81a3@mail.gmail.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 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: Mon, 19 Sep 2005 16:03:16 -0000 On Mon, 19 Sep 2005 16:11:27 +0100 Joao Barros wrote: > On 9/16/05, 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=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@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